Document Purpose
Confirmed by requirements: this software update standard contributes 205 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
CVS123-2
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
CVS123-2
Software Update Standard · Hardware / Platform · Core ECA system behavior
Executive Takeaway
Confirmed by requirements: this software update standard contributes 205 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; system architecture design; responsibility and customer approval model.
Confirmed by requirements: supplier positioning is 68 accept; 47 accept with assumption; 73 partially accept; 1 needs customer clarification; 1 needs internal review (showing 5 of 6). The generated traceability links this document to 31 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; system architecture design; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Requirements205from this PDF
Critical74ranked
Open Points3linked
Derived SSRs31linked
Concept Impactyesdocument-specific
Estimation Impactyesdocument-specific
Document Abstract
Engineering Interpretation
Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; system architecture design; responsibility and customer approval model.
Main Requirement Themes
Core ECA system behavior; System architecture design; Responsibility and customer approval model; Software; Application software (showing 5 of 8)
System / Security Impact
Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; system architecture design; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Supplier Proposal Impact
Confirmed by requirements: supplier positioning is 68 accept; 47 accept with assumption; 73 partially accept; 1 needs customer clarification; 1 needs internal review (showing 5 of 6). The generated traceability links this document to 31 supplier system requirement records.
Customer Clarification Impact
Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). Do not convert these items into agreed baseline scope until the customer confirms the decision.
Confidence and Limits
Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Main Requirement Themes
| Theme | Engineering Meaning | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 172 | REQ-AUTO-00279; REQ-AUTO-00280; REQ-AUTO-00281 |
| System architecture design | Groups related document requirements into a single engineering theme. | 130 | REQ-AUTO-00279; REQ-AUTO-00281; REQ-AUTO-00284 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 103 | REQ-AUTO-00279; REQ-AUTO-00280; REQ-AUTO-00282 |
| Software | Groups related document requirements into a single engineering theme. | 89 | REQ-AUTO-00279; REQ-AUTO-00284; REQ-AUTO-00286 |
| Application software | Groups related document requirements into a single engineering theme. | 84 | REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288 |
| Application software behavior | Groups related document requirements into a single engineering theme. | 84 | REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 80 | REQ-AUTO-00280; REQ-AUTO-00282; REQ-AUTO-00283 |
| Secure software update and bootloader | Defines ECU-side programming, boot/application state handling, integrity checks, and update evidence. | 67 | REQ-AUTO-00279; REQ-AUTO-00284; REQ-AUTO-00290 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 2 Overview | 4 | 1 | 1 | 2 |
| -- 2.1 Summary | 3 | 1 | 1 | 1 |
| -- 2.3 Relation to other specifications | 1 | 0 | 0 | 1 |
| 3 Terms, definitions and abbrevations | 12 | 0 | 0 | 3 |
| -- 3.1 Definitions of terms | 10 | 0 | 0 | 2 |
| -- 3.2 Abbreviated terms | 2 | 0 | 0 | 1 |
| 4 General requirements | 30 | 7 | 3 | 11 |
| -- 4.2 Software architecture requirements | 8 | 2 | 1 | 4 |
| -- 4.3 Software distribution requirements | 10 | 1 | 1 | 6 |
| 5 Detailed programming sequence | 19 | 11 | 2 | 11 |
| -- 5.1 Programming phase #1 – Download of application software and/or application data | 13 | 6 | 0 | 8 |
| -- -- 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming | 4 | 1 | 0 | 1 |
| -- -- 5.1.2 Programming step of phase #1 – Download of application software and data | 4 | 3 | 0 | 3 |
| -- -- 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network | 1 | 0 | 0 | 0 |
| -- -- 5.1.4 Programming Phase #2 | 4 | 2 | 0 | 4 |
| 6 Server reprogramming requirements | 29 | 7 | 2 | 10 |
| -- 6.1 Requirements for servers to support programming | 29 | 7 | 2 | 10 |
| -- -- 6.1.1 Boot software description and requirements | 14 | 4 | 2 | 7 |
| 7 Diagnostic service requirements | 29 | 18 | 1 | 7 |
| -- 7.1 RequestDownload (0x34) Service | 16 | 11 | 1 | 7 |
| -- -- 7.1.1 Request | 5 | 3 | 0 | 4 |
| -- -- 7.1.4 Service 0x34 Parameters | 6 | 5 | 0 | 3 |
| -- 7.2 TransferData (0x36) Service | 6 | 3 | 0 | 3 |
| -- -- 7.2.4 Service 0x36 Parameters | 6 | 3 | 0 | 3 |
| -- 7.4 SecuredDataTranmission (0x84) Service | 7 | 4 | 0 | 2 |
| -- -- 7.4.1 Request | 7 | 4 | 0 | 2 |
| 8 Diagnostic Routine Identifier Requirements | 49 | 22 | 2 | 15 |
| -- 8.1 Routine Session and routineControlSupport | 6 | 3 | 1 | 5 |
| -- -- 8.1.1 Routine Session Support | 6 | 3 | 1 | 5 |
| -- 8.2 Routine 0x2202 – Check Memory Block | 6 | 3 | 1 | 5 |
| -- -- 8.2.3 Negative Response | 2 | 0 | 0 | 2 |
| -- 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) | 12 | 3 | 1 | 8 |
| -- -- 8.3.2 Routine Positive Response | 2 | 0 | 0 | 1 |
| -- -- 8.3.4 Routine 0xFF00 Parameters | 4 | 1 | 1 | 4 |
| -- 8.4 Routine 0xFF01 – CheckProgrammingDependencies | 18 | 8 | 2 | 8 |
| -- -- 8.4.1 Request | 9 | 3 | 0 | 6 |
| -- -- 8.4.4 Routine 0xFF01 Parameters | 9 | 5 | 2 | 6 |
| -- 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) | 7 | 5 | 2 | 4 |
| -- -- 8.5.4 Routine 0xCAFE Parameters | 4 | 3 | 0 | 2 |
| 9 Software Verification and Encryption Requirements | 15 | 2 | 0 | 9 |
| -- 9.1 General Requirements on SDSC | 8 | 1 | 0 | 6 |
| -- -- 9.1.2 SDSC Sanity Check | 8 | 1 | 0 | 6 |
| -- 9.2 Software Verification | 7 | 1 | 0 | 5 |
| 10 Non-volatile server memory programming complete flow | 11 | 4 | 0 | 6 |
| 11 Normative references | 3 | 2 | 0 | 3 |
What This PDF Is About
| Field | Value |
|---|---|
| Source PDF | customer-input/pdf/CVS123-2.pdf |
| Converted Markdown | converted/markdown/CVS123-2.md |
| Document Type | Software Update Standard |
| Domain | Hardware / Platform |
| Scope Summary | 205 extracted requirements; 31 linked SSRs; 3 linked open points. |
| Main Themes | Core ECA system behavior; System architecture design; Responsibility and customer approval model; Software; Application software (showing 5 of 8) |
| Does Not Confirm | Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed. |
| Confidence | High |
| Evidence Basis | Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis. |
Key Conclusions From This PDF
- Confirmed by requirements: this software update standard contributes 205 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
- Confirmed by requirements: supplier positioning is 68 accept; 47 accept with assumption; 73 partially accept; 1 needs customer clarification; 1 needs internal review (showing 5 of 6). The generated traceability links this document to 31 supplier system requirement records.
- Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). Do not convert these items into agreed baseline scope until the customer confirms the decision.
Critical Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| REQ-AUTO-00317 | 95 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | Needs Customer Clarification |
| REQ-AUTO-00282 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00299 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00310 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00333 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00334 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00350 | 77 | High risk due to unclear OEM/supplier responsibility | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00377 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00411 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00412 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00413 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00429 | 77 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
Customer Clarifications / Open Points
Total Open Points3document-linked
P10priority
P20priority
Blocking Conceptyesyes/no
Blocking Estimationyesyes/no
Blocking SSRyesyes/no
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Open Point | Priority | Question / Impact | Required Customer Decision | Recommended Supplier Position | Owner | Status |
|---|---|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table. | Shared (OEM policy / Supplier ECU) | Open | |
| OP-004 | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.Update-control scope and evidence ownership stay open; risk of an unprotected update path. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Implement authenticated, integrity-protected ECU programming with controlled boot/app state; require OEM update-chain definition. | Shared (OEM backend / Supplier ECU) | Open | |
| OP-008 | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).Hardware fusing and EOL process design stay open; risk of an exposed debug/production interface. | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Apply debug lock and secured production access; request the customer-confirmed production-security and EOL requirements. | Shared (OEM process / Supplier ECU) | Open |
Requirements From This PDF
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Proposal | Supplier Position | Review | Security Capability | Feature / Interface | SSR | Open Point | Source |
|---|---|---|---|---|---|---|---|---|
| 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.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. | Needs Customer Clarification | Reviewed Internally | None | Backend and IT integration None | None | OP-004 | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 2.1 Summary page 4 Source detailsDocument section 2.1 Summary Section path 2 Overview > 2.1 Summary Page reference page 4 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Partially Accept | Proposal Ready | Authentication | Authentication; Secure software update and flash readiness None | SSR-RBAC-002 | OP-002 | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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.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. | Partially Accept | Proposal Ready | Authentication | Authentication; Secure software update and flash readiness None | SSR-RBAC-002 | OP-002 | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 7.1 RequestDownload (0x34) Service page 24 Source detailsDocument section 7.1 RequestDownload (0x34) Service Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service Page reference page 24 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 8.2 Routine 0x2202 – Check Memory Block page 30 Source detailsDocument section 8.2 Routine 0x2202 – Check Memory Block Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block Page reference page 30 |
| 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.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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security; Secure software update and flash readiness None | SSR-RBAC-001 | OP-002 | 8.2 Routine 0x2202 – Check Memory Block page 30 Source detailsDocument section 8.2 Routine 0x2202 – Check Memory Block Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block Page reference page 30 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-BOOT-001 | OP-004 | 8.3.4 Routine 0xFF00 Parameters page 34 Source detailsDocument section 8.3.4 Routine 0xFF00 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.4 Routine 0xFF00 Parameters Page reference page 34 |
| 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: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. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 8.4.4 Routine 0xFF01 Parameters page 36 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 36 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness; Security evidence and traceability OEM/Customer Review Interface | SSR-UPD-003 | OP-004 | 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) page 38 Source detailsDocument section 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page reference page 38 |
| 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 RequestTransferExitProposal: Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) page 38 Source detailsDocument section 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page reference page 38 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | OP-004 | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | OP-004 | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | OP-008 | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00329 | Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter.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. | Partially Accept | Proposal Ready | None | System behavior; Secure software update and flash readiness None | SSR-UPD-001 | OP-004 | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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).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. | Partially Accept | Proposal Ready | None | System behavior; Secure software update and flash readiness None | SSR-UPD-001 | OP-004 | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-005 | OP-004 | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration; Secure software update and flash readiness None | SSR-UPD-005 | OP-002 | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | OP-004 | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-003 | OP-004 | 6.1.1 Boot software description and requirements page 23 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 23 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | OP-004 | 6.1.1 Boot software description and requirements page 23 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 23 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration; Secure software update and flash readiness None | SSR-UPD-005 | OP-004 | 8.4.4 Routine 0xFF01 Parameters page 36 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 36 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming page 14 Source detailsDocument section 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page reference page 14 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 5.1.2 Programming step of phase #1 – Download of application software and data page 16 Source detailsDocument section 5.1.2 Programming step of phase #1 – Download of application software and data Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.2 Programming step of phase #1 – Download of application software and data Page reference page 16 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-RBAC-004 | - | 5.1.4 Programming Phase #2 page 20 Source detailsDocument section 5.1.4 Programming Phase #2 Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.4 Programming Phase #2 Page reference page 20 |
| REQ-AUTO-00353 | SUV2_REQ 38 The server shall be able to update an individual module independently from any other module.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| REQ-AUTO-00436 | SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| REQ-AUTO-00445 | SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.4 Routine 0xFF01 Parameters page 37 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 37 |
| 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).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. | Partially Accept | Proposal Ready | Secure communication | Secure communication; Security evidence and traceability OEM/Customer Review Interface | SSR-COM-007 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration OEM/Customer Review Interface | SSR-DIAG-003 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | - | 5.1.2 Programming step of phase #1 – Download of application software and data page 16 Source detailsDocument section 5.1.2 Programming step of phase #1 – Download of application software and data Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.2 Programming step of phase #1 – Download of application software and data Page reference page 16 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 5.1.2 Programming step of phase #1 – Download of application software and data page 16 Source detailsDocument section 5.1.2 Programming step of phase #1 – Download of application software and data Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.2 Programming step of phase #1 – Download of application software and data Page reference page 16 |
| 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.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Hardware platform support None | SSR-LOG-002 | - | 5.1.4 Programming Phase #2 page 20 Source detailsDocument section 5.1.4 Programming Phase #2 Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.4 Programming Phase #2 Page reference page 20 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1 RequestDownload (0x34) Service page 24 Source detailsDocument section 7.1 RequestDownload (0x34) Service Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service Page reference page 24 |
| 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 0x24Proposal: Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1 RequestDownload (0x34) Service page 24 Source detailsDocument section 7.1 RequestDownload (0x34) Service Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service Page reference page 24 |
| REQ-AUTO-00383 | SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC.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. | Partially Accept | Proposal Ready | None | Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-002 | - | 7.1.1 Request page 25 Source detailsDocument section 7.1.1 Request Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.1 Request Page reference page 25 |
| REQ-AUTO-00385 | SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1.1 Request page 25 Source detailsDocument section 7.1.1 Request Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.1 Request Page reference page 25 |
| REQ-AUTO-00386 | 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1.1 Request page 25 Source detailsDocument section 7.1.1 Request Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.1 Request Page reference page 25 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-003 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-003 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| REQ-AUTO-00391 | SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| REQ-AUTO-00394 | 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| REQ-AUTO-00404 | 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DAI-004 | - | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | - | 8.2 Routine 0x2202 – Check Memory Block page 30 Source detailsDocument section 8.2 Routine 0x2202 – Check Memory Block Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block Page reference page 30 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| 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).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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| REQ-AUTO-00435 | SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| REQ-AUTO-00437 | SUV2_REQ 121 The integrity check shall be carried out solely by the server.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DAI-004 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-DAI-003 | - | 8.4.4 Routine 0xFF01 Parameters page 36 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 36 |
| REQ-AUTO-00446 | SUV2_REQ 174 The server shall use ED25519 as signature algorithm.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DAI-004 | - | 8.4.4 Routine 0xFF01 Parameters page 37 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 37 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 8.5.4 Routine 0xCAFE Parameters page 39 Source detailsDocument section 8.5.4 Routine 0xCAFE Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) > 8.5.4 Routine 0xCAFE Parameters Page reference page 39 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 8.5.4 Routine 0xCAFE Parameters page 39 Source detailsDocument section 8.5.4 Routine 0xCAFE Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) > 8.5.4 Routine 0xCAFE Parameters Page reference page 39 |
| 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.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. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 8.5.4 Routine 0xCAFE Parameters page 39 Source detailsDocument section 8.5.4 Routine 0xCAFE Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) > 8.5.4 Routine 0xCAFE Parameters Page reference page 39 |
| REQ-AUTO-00464 | 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC.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. | Partially Accept | Proposal Ready | None | Application software behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-003 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| 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.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. | Partially Accept | Proposal Ready | None | Hardware platform support None | SSR-HW-001 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| REQ-AUTO-00471 | SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned.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. | Partially Accept | Proposal Ready | None | Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface | SSR-VV-002 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| REQ-AUTO-00473 | SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-DAI-003 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| 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.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. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| 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.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Hardware platform support None | SSR-SDT-002 | - | 11 Normative references page 50 Source detailsDocument section 11 Normative references Section path 11 Normative references Page reference page 50 |
| 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.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 11 Normative references page 50 Source detailsDocument section 11 Normative references Section path 11 Normative references Page reference page 50 |
| 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.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. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security; Secure software update and flash readiness None | SSR-RBAC-001 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| 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”.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. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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 0xF197Proposal: Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| REQ-AUTO-00322 | SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer.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. | Accept with Assumption | Proposal Ready | None | System behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-001 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00323 | SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files.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. | Accept with Assumption | Proposal Ready | None | System behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-001 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| 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.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. | Accept with Assumption | Proposal Ready | None | External interfaces; Secure software update and flash readiness External Interfaces; OEM/Customer Review Interface | SSR-UPD-004 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness; Security evidence and traceability OEM/Customer Review Interface | SSR-UPD-003 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00370 | 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124.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. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| 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.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. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | - | 6.1.1 Boot software description and requirements page 23 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 23 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-003 | - | 6.1.1 Boot software description and requirements page 23 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 23 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 7.1 RequestDownload (0x34) Service page 24 Source detailsDocument section 7.1 RequestDownload (0x34) Service Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service Page reference page 24 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Hardware platform support; Secure software update and flash readiness None | SSR-BOOT-002 | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-003 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure software update and flash readiness None | None | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| 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 memoryProposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure software update and flash readiness None | None | - | 3.2 Abbreviated terms page 7 Source detailsDocument section 3.2 Abbreviated terms Section path 3 Terms, definitions and abbrevations > 3.2 Abbreviated terms Page reference page 7 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming page 14 Source detailsDocument section 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page reference page 14 |
| REQ-AUTO-00337 | Alternatively, it may be a client strategy to always update certain entities prior to a software update.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure software update and flash readiness None | None | - | 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming page 14 Source detailsDocument section 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page reference page 14 |
| 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.Proposal: Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Needs Internal Review | Reviewed Internally | None | Backend and IT integration None | None | - | 2.1 Summary page 4 Source detailsDocument section 2.1 Summary Section path 2 Overview > 2.1 Summary Page reference page 4 |
| REQ-AUTO-00291 | shall be implemented in the boot software code.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ_UDS-0051 | 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 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).Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Application software behavior; System behavior; Secure software update and flash readiness None | None | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ_UDS-0051 | 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 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).Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Application software behavior; System behavior; Secure software update and flash readiness None | None | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Hardware platform support; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-002 | - | 3.2 Abbreviated terms page 7 Source detailsDocument section 3.2 Abbreviated terms Section path 3 Terms, definitions and abbrevations > 3.2 Abbreviated terms Page reference page 7 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-BOOT-001 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-BOOT-001 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Hardware platform support; Secure software update and flash readiness None | SSR-BOOT-002 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Accept with Assumption | Proposal Ready | None | System behavior; Secure software update and flash readiness None | SSR-UPD-001 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| REQ-AUTO-00308 | SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards.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. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-BOOT-003 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-003 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness; Security evidence and traceability OEM/Customer Review Interface | SSR-UPD-003 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| REQ-AUTO-00314 | SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs.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. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-004 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-BOOT-001 | - | 4.2 Software architecture requirements page 10 Source detailsDocument section 4.2 Software architecture requirements Section path 4 General requirements > 4.2 Software architecture requirements Page reference page 10 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior OEM/Customer Review Interface | SSR-SYS-007 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior OEM/Customer Review Interface | SSR-SYS-007 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-BOOT-001 | - | 5 Detailed programming sequence page 12 Source detailsDocument section 5 Detailed programming sequence Section path 5 Detailed programming sequence Page reference page 12 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Application software behavior OEM/Customer Review Interface | None | - | 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming page 15 Source detailsDocument section 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page reference page 15 |
| REQ_UDS-0051 | 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 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).Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Application software behavior; System behavior; Secure software update and flash readiness None | None | - | 5.1.2 Programming step of phase #1 – Download of application software and data page 17 Source detailsDocument section 5.1.2 Programming step of phase #1 – Download of application software and data Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.2 Programming step of phase #1 – Download of application software and data Page reference page 17 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | - | 5.1.4 Programming Phase #2 page 20 Source detailsDocument section 5.1.4 Programming Phase #2 Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.4 Programming Phase #2 Page reference page 20 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Hardware platform support; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-002 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-BOOT-001 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-BOOT-003 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-BOOT-003 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| REQ-AUTO-00363 | Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| REQ-AUTO-00364 | SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer.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. | Accept with Assumption | Proposal Ready | None | System behavior; Secure software update and flash readiness OEM/Customer Review Interface | SSR-UPD-001 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| REQ-AUTO-00371 | SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported.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. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | - | 7.1.1 Request page 25 Source detailsDocument section 7.1.1 Request Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.1 Request Page reference page 25 |
| REQ-AUTO-00415 | SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 8.2 Routine 0x2202 – Check Memory Block page 30 Source detailsDocument section 8.2 Routine 0x2202 – Check Memory Block Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block Page reference page 30 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SDT-001 | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Application software behavior; Secure software update and flash readiness None | SSR-UPD-003 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| 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.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. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-004 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| REQ-AUTO-00459 | SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC.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. | Accept with Assumption | Proposal Ready | None | Application software behavior OEM/Customer Review Interface | SSR-SYS-008 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| 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.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| 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.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. | Accept with Assumption | Proposal Ready | None | Hardware platform support None | SSR-COM-005 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| 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).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. | Accept with Assumption | Proposal Ready | None | Hardware platform support; Secure software update and flash readiness None | SSR-UPD-002 | - | 11 Normative references page 48 Source detailsDocument section 11 Normative references Section path 11 Normative references Page reference page 48 |
| REQ-AUTO-00284 | Clients may prefer to implement programming support using other service parameter values or even another set of programming steps thanProposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Secure software update and flash readiness None | None | - | 2.1 Summary page 4 Source detailsDocument section 2.1 Summary Section path 2 Overview > 2.1 Summary Page reference page 4 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network page 19 Source detailsDocument section 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page reference page 19 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 7.1 RequestDownload (0x34) Service page 24 Source detailsDocument section 7.1 RequestDownload (0x34) Service Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service Page reference page 24 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| 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”.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-009 | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00281 | The User shall apply the latest version of this CVS123-2.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00285 | For this reason, only the server is required to support the specified sequence.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 2.3 Relation to other specifications page 5 Source detailsDocument section 2.3 Relation to other specifications Section path 2 Overview > 2.3 Relation to other specifications Page reference page 5 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ-AUTO-00287 | It must be clearly separated from the application software.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ-AUTO-00289 | Application software module Contains all vehicle functions required for the normal server operation.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ-AUTO-00296 | The value of this variable may be used by the application to determine whether or not initialization is required.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 3.1 Definitions of terms page 6 Source detailsDocument section 3.1 Definitions of terms Section path 3 Terms, definitions and abbrevations > 3.1 Definitions of terms Page reference page 6 |
| REQ-AUTO-00301 | SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s).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. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-004 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| REQ-AUTO-00304 | A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| REQ-AUTO-00305 | If the microcontroller supports HW protection, this shall be used.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 4 General requirements page 9 Source detailsDocument section 4 General requirements Section path 4 General requirements Page reference page 9 |
| 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”.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00320 | SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer.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. | Accept | Proposal Ready | None | Application software behavior OEM/Customer Review Interface | SSR-SYS-007 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00328 | Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 4.3 Software distribution requirements page 11 Source detailsDocument section 4.3 Software distribution requirements Section path 4 General requirements > 4.3 Software distribution requirements Page reference page 11 |
| REQ-AUTO-00344 | SUV2_INFO 93 If the application was started, it checks if application initialization is required.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 5.1.4 Programming Phase #2 page 20 Source detailsDocument section 5.1.4 Programming Phase #2 Section path 5 Detailed programming sequence > 5.1 Programming phase #1 – Download of application software and/or application data > 5.1.4 Programming Phase #2 Page reference page 20 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| REQ-AUTO-00352 | SUV2_REQ 37 Application software and application data modules shall be programmable in any order.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| REQ-AUTO-00356 | SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer.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. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-004 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| REQ-AUTO-00357 | SUV2_REQ 42 It shall be possible to program the same software version repeatedly.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 6.1 Requirements for servers to support programming page 21 Source detailsDocument section 6.1 Requirements for servers to support programming Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming Page reference page 21 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| REQ-AUTO-00368 | The causes specified in (ISO14229-1:2020) shall be regarded as examples.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-007 | - | 6.1.1 Boot software description and requirements page 22 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 22 |
| REQ-AUTO-00376 | 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 6.1.1 Boot software description and requirements page 23 Source detailsDocument section 6.1.1 Boot software description and requirements Section path 6 Server reprogramming requirements > 6.1 Requirements for servers to support programming > 6.1.1 Boot software description and requirements Page reference page 23 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.1.1 Request page 25 Source detailsDocument section 7.1.1 Request Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.1 Request Page reference page 25 |
| REQ-AUTO-00392 | 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.1.4 Service 0x34 Parameters page 26 Source detailsDocument section 7.1.4 Service 0x34 Parameters Section path 7 Diagnostic service requirements > 7.1 RequestDownload (0x34) Service > 7.1.4 Service 0x34 Parameters Page reference page 26 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| REQ-AUTO-00396 | 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.2.4 Service 0x36 Parameters page 27 Source detailsDocument section 7.2.4 Service 0x36 Parameters Section path 7 Diagnostic service requirements > 7.2 TransferData (0x36) Service > 7.2.4 Service 0x36 Parameters Page reference page 27 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| REQ-AUTO-00403 | 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| REQ-AUTO-00405 | 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 7.4.1 Request page 28 Source detailsDocument section 7.4.1 Request Section path 7 Diagnostic service requirements > 7.4 SecuredDataTranmission (0x84) Service > 7.4.1 Request Page reference page 28 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| REQ-AUTO-00407 | 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| 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.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. | Accept | Proposal Ready | None | Secure communication and freshness protection; Backend and IT integration None | SSR-COM-006 | - | 8.1.1 Routine Session Support page 29 Source detailsDocument section 8.1.1 Routine Session Support Section path 8 Diagnostic Routine Identifier Requirements > 8.1 Routine Session and routineControlSupport > 8.1.1 Routine Session Support Page reference page 29 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-DAI-004 | - | 8.2.3 Negative Response page 31 Source detailsDocument section 8.2.3 Negative Response Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block > 8.2.3 Negative Response Page reference page 31 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-DIAG-003 | - | 8.2.3 Negative Response page 31 Source detailsDocument section 8.2.3 Negative Response Section path 8 Diagnostic Routine Identifier Requirements > 8.2 Routine 0x2202 – Check Memory Block > 8.2.3 Negative Response Page reference page 31 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-DIAG-003 | - | 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) page 32 Source detailsDocument section 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page reference page 32 |
| REQ-AUTO-00424 | Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.3.2 Routine Positive Response page 33 Source detailsDocument section 8.3.2 Routine Positive Response Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.2 Routine Positive Response Page reference page 33 |
| REQ-AUTO-00425 | 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.3.2 Routine Positive Response page 33 Source detailsDocument section 8.3.2 Routine Positive Response Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.2 Routine Positive Response Page reference page 33 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.3.4 Routine 0xFF00 Parameters page 34 Source detailsDocument section 8.3.4 Routine 0xFF00 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.4 Routine 0xFF00 Parameters Page reference page 34 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 8.3.4 Routine 0xFF00 Parameters page 34 Source detailsDocument section 8.3.4 Routine 0xFF00 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.4 Routine 0xFF00 Parameters Page reference page 34 |
| 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.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 8.3.4 Routine 0xFF00 Parameters page 34 Source detailsDocument section 8.3.4 Routine 0xFF00 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) > 8.3.4 Routine 0xFF00 Parameters Page reference page 34 |
| REQ-AUTO-00431 | SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| 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).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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| REQ-AUTO-00434 | SUV2_REQ 118 The consistency check shall be carried out solely by the server.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| REQ-AUTO-00438 | 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.1 Request page 35 Source detailsDocument section 8.4.1 Request Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.1 Request Page reference page 35 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.4 Routine 0xFF01 Parameters page 36 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 36 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.4 Routine 0xFF01 Parameters page 37 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 37 |
| REQ-AUTO-00444 | SUV2_REQ 172 The hash algorithm shall be SHA512.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 8.4.4 Routine 0xFF01 Parameters page 37 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 37 |
| REQ-AUTO-00447 | SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.4.4 Routine 0xFF01 Parameters page 37 Source detailsDocument section 8.4.4 Routine 0xFF01 Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.4 Routine 0xFF01 – CheckProgrammingDependencies > 8.4.4 Routine 0xFF01 Parameters Page reference page 37 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) page 38 Source detailsDocument section 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page reference page 38 |
| REQ-AUTO-00451 | Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-001 | - | 8.5.4 Routine 0xCAFE Parameters page 39 Source detailsDocument section 8.5.4 Routine 0xCAFE Parameters Section path 8 Diagnostic Routine Identifier Requirements > 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) > 8.5.4 Routine 0xCAFE Parameters Page reference page 39 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| REQ-AUTO-00457 | SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field.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. | Accept | Proposal Ready | None | Hardware platform support None | SSR-HW-001 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| REQ-AUTO-00458 | SUV2_REQ 185 The range length field shall be the number of bytes to be verified.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| REQ-AUTO-00460 | SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator.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. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-009 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| 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.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 9.1.2 SDSC Sanity Check page 40 Source detailsDocument section 9.1.2 SDSC Sanity Check Section path 9 Software Verification and Encryption Requirements > 9.1 General Requirements on SDSC > 9.1.2 SDSC Sanity Check Page reference page 40 |
| REQ-AUTO-00463 | SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| REQ-AUTO-00466 | SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing.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. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 9.2 Software Verification page 41 Source detailsDocument section 9.2 Software Verification Section path 9 Software Verification and Encryption Requirements > 9.2 Software Verification Page reference page 41 |
| REQ-AUTO-00472 | SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| 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.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. | Accept | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| 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.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-004 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| REQ-AUTO-00477 | SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| REQ-AUTO-00478 | SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| REQ-AUTO-00479 | Other methods shall be agreed upon with OEM.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. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
| 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.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Application software behavior None | None | - | 10 Non-volatile server memory programming complete flow page 42 Source detailsDocument section 10 Non-volatile server memory programming complete flow Section path 10 Non-volatile server memory programming complete flow Page reference page 42 |
Derived Supplier System Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| SSR | Statement / Trace | Feature | Security Capability | Interface | Responsibility | Status | Verification |
|---|---|---|---|---|---|---|---|
| SSR-BOOT-001 | Application software behavior — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Application software behavior and enforce the defined behaviour on verification failure.From this PDF: REQ-AUTO-00300; REQ-AUTO-00302; REQ-AUTO-00316; REQ-AUTO-00331; REQ-AUTO-00359; REQ-AUTO-00429. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-BOOT-002 | Hardware platform support — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Hardware platform support and enforce the defined behaviour on verification failure.From this PDF: REQ-AUTO-00303; REQ-AUTO-00421. This SSR is also supported by requirements from other PDFs. | Hardware platform support | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-BOOT-003 | System behavior — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for System behavior and enforce the defined behaviour on verification failure.From this PDF: REQ-AUTO-00308; REQ-AUTO-00361; REQ-AUTO-00362. This SSR is also supported by requirements from other PDFs. | System behavior | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-COM-005 | Hardware platform support — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Hardware platform support, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00467. This SSR is also supported by requirements from other PDFs. | Hardware platform support | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-COM-006 | Secure communication and freshness protection — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00410. This SSR is also supported by requirements from other PDFs. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-COM-007 | OEM/Customer Review Interface — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00455. | OEM/Customer Review Interface | Secure communication | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-DAI-003 | Application software behavior — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Application software behavior data and reject manipulated or unauthenticated data.From this PDF: REQ-AUTO-00321; REQ-AUTO-00339; REQ-AUTO-00414; REQ-AUTO-00435; REQ-AUTO-00436; REQ-AUTO-00441; REQ-AUTO-00473. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-DAI-004 | Backend and IT integration — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Backend and IT integration data and reject manipulated or unauthenticated data.From this PDF: REQ-AUTO-00409; REQ-AUTO-00416; REQ-AUTO-00437; REQ-AUTO-00446. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-DIAG-003 | Backend and IT integration — Diagnostic ServicesThe ECU shall provide the diagnostic services for Backend and IT integration required by the allocated customer requirements, including the specified services, sessions and data identifiers.From this PDF: REQ-AUTO-00309; REQ-AUTO-00417; REQ-AUTO-00418. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-HW-001 | Hardware platform support — Hardware / HSM / Secure StorageThe ECU hardware shall provide the platform and secure-storage capabilities required for Hardware platform support.From this PDF: REQ-AUTO-00457; REQ-AUTO-00470. This SSR is also supported by requirements from other PDFs. | Hardware platform support | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-LOG-002 | Hardware platform support — Security Logging and Event HandlingThe ECU shall record bounded security-relevant events for Hardware platform support with sufficient integrity and context for diagnostics and incident evidence.From this PDF: REQ-AUTO-00345. | Hardware platform support | None | None | Shared | Ready for Customer Alignment | Review + Test |
| SSR-RBAC-001 | Diagnostic security — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Diagnostic security, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00282; REQ-AUTO-00290; REQ-AUTO-00299; REQ-AUTO-00310; REQ-AUTO-00315; REQ-AUTO-00318; REQ-AUTO-00350; REQ-AUTO-00370; REQ-AUTO-00372; REQ-AUTO-00377; REQ-AUTO-00411; REQ-AUTO-00412; REQ-AUTO-00413; REQ-AUTO-00442; REQ-AUTO-00450. This SSR is also supported by requirements from other PDFs. | Diagnostic security | Diagnostic security | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-002 | Authentication — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00333; REQ-AUTO-00334. This SSR is also supported by requirements from other PDFs. | Authentication | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-003 | Backend and IT integration — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00336. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00347. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-SDT-001 | Application software behavior — Secure Data Transfer / Data Security ContainerThe ECU shall protect security-relevant data transfer for Application software behavior using the agreed secured data transfer / data security container scheme.From this PDF: REQ-AUTO-00341; REQ-AUTO-00380; REQ-AUTO-00395; REQ-AUTO-00398; REQ-AUTO-00415; REQ-AUTO-00423. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | None | Shared | Ready for Customer Alignment | Review + Test |
| SSR-SDT-002 | Hardware platform support — Secure Data Transfer / Data Security ContainerThe ECU shall protect security-relevant data transfer for Hardware platform support using the agreed secured data transfer / data security container scheme.From this PDF: REQ-AUTO-00482. | Hardware platform support | None | None | Shared | Ready for Customer Alignment | Review + Test |
| SSR-SYS-004 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00281; REQ-AUTO-00301; REQ-AUTO-00305; REQ-AUTO-00314; REQ-AUTO-00328; REQ-AUTO-00354; REQ-AUTO-00355; REQ-AUTO-00356; REQ-AUTO-00368; REQ-AUTO-00371; REQ-AUTO-00428; REQ-AUTO-00433; REQ-AUTO-00444; REQ-AUTO-00458; REQ-AUTO-00476. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test |
| SSR-SYS-005 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00477; REQ-AUTO-00478; REQ-AUTO-00479. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-SYS-007 | Application software behavior — System FunctionThe ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288; REQ-AUTO-00289; REQ-AUTO-00291; REQ-AUTO-00296; REQ-AUTO-00304; REQ-AUTO-00319; REQ-AUTO-00320; REQ-AUTO-00325; REQ-AUTO-00327; REQ-AUTO-00332; REQ-AUTO-00344; REQ-AUTO-00351; REQ-AUTO-00352; REQ-AUTO-00357; REQ-AUTO-00360; REQ-AUTO-00369; REQ-AUTO-00379; REQ-AUTO-00381; REQ-AUTO-00385; REQ-AUTO-00386; REQ-AUTO-00387; REQ-AUTO-00388; REQ-AUTO-00391; REQ-AUTO-00394; REQ-AUTO-00400; REQ-AUTO-00401; REQ-AUTO-00402; REQ-AUTO-00404; REQ-AUTO-00408; REQ-AUTO-00419. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Test |
| SSR-SYS-008 | Application software behavior — System FunctionThe ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00422; REQ-AUTO-00427; REQ-AUTO-00432; REQ-AUTO-00459; REQ-AUTO-00461; REQ-AUTO-00465; REQ-AUTO-00468; REQ-AUTO-00472; REQ-AUTO-00474; REQ-AUTO-00475. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-SYS-009 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00280; REQ-AUTO-00460. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test |
| SSR-TOOL-001 | Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00285; REQ-AUTO-00340; REQ-AUTO-00353; REQ-AUTO-00365; REQ-AUTO-00376; REQ-AUTO-00384; REQ-AUTO-00392; REQ-AUTO-00393; REQ-AUTO-00396; REQ-AUTO-00397; REQ-AUTO-00399; REQ-AUTO-00403; REQ-AUTO-00405; REQ-AUTO-00406; REQ-AUTO-00407; REQ-AUTO-00424; REQ-AUTO-00425; REQ-AUTO-00426; REQ-AUTO-00431; REQ-AUTO-00434; REQ-AUTO-00438; REQ-AUTO-00439; REQ-AUTO-00443; REQ-AUTO-00445; REQ-AUTO-00447; REQ-AUTO-00449; REQ-AUTO-00451. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Ready for Customer Alignment | Review + Test |
| SSR-TOOL-002 | Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00452; REQ-AUTO-00453; REQ-AUTO-00454; REQ-AUTO-00456; REQ-AUTO-00462; REQ-AUTO-00463; REQ-AUTO-00466; REQ-AUTO-00483. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-UPD-001 | System behavior — Software Update / FlashingThe ECU shall support secure software update/flashing for System behavior, accepting only authenticated, integrity-verified software through the agreed programming sequence.From this PDF: REQ-AUTO-00307; REQ-AUTO-00322; REQ-AUTO-00323; REQ-AUTO-00329; REQ-AUTO-00330; REQ-AUTO-00364. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-UPD-002 | Hardware platform support — Software Update / FlashingThe ECU shall support secure software update/flashing for Hardware platform support, accepting only authenticated, integrity-verified software through the agreed programming sequence.From this PDF: REQ-AUTO-00297; REQ-AUTO-00349; REQ-AUTO-00481. This SSR is also supported by requirements from other PDFs. | Hardware platform support | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test |
| SSR-UPD-003 | Application software behavior — Software Update / FlashingThe ECU shall support secure software update/flashing for Application software behavior, accepting only authenticated, integrity-verified software through the agreed programming sequence.From this PDF: REQ-AUTO-00306; REQ-AUTO-00311; REQ-AUTO-00312; REQ-AUTO-00313; REQ-AUTO-00326; REQ-AUTO-00346; REQ-AUTO-00358; REQ-AUTO-00363; REQ-AUTO-00367; REQ-AUTO-00373; REQ-AUTO-00374; REQ-AUTO-00375; REQ-AUTO-00382; REQ-AUTO-00430; REQ-AUTO-00448; REQ-AUTO-00469. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-UPD-004 | External interfaces — Software Update / FlashingThe ECU shall support secure software update/flashing for External interfaces, accepting only authenticated, integrity-verified software through the agreed programming sequence.From this PDF: REQ-AUTO-00324. | External interfaces | None | External Interfaces | Supplier-Owned | Candidate | Review + Test |
| SSR-UPD-005 | Backend and IT integration — Software Update / FlashingThe ECU shall support secure software update/flashing for Backend and IT integration, accepting only authenticated, integrity-verified software through the agreed programming sequence.From this PDF: REQ-AUTO-00348; REQ-AUTO-00366; REQ-AUTO-00440. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-VV-002 | Backend and IT integration — Verification and ValidationThe supplier shall verify and validate Backend and IT integration per the agreed cybersecurity verification and validation plan.From this PDF: REQ-AUTO-00383; REQ-AUTO-00471. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-VV-003 | Application software behavior — Verification and ValidationThe supplier shall verify and validate Application software behavior per the agreed cybersecurity verification and validation plan.From this PDF: REQ-AUTO-00389; REQ-AUTO-00390; REQ-AUTO-00464. | Application software behavior | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
System / Security Design Impact
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Application software behavior; Application software behavior; Secure software update and flash readiness; Application software behavior; Secure software update and flash readiness; Security evidence and traceability; Application software behavior; Security evidence and traceability; Application software behavior; System behavior; Secure software update and flash readiness; Authentication; Secure software update and flash readiness; Backend and IT integration; Backend and IT integration; Secure software update and flash readiness; Backend and IT integration; Security evidence and traceability; Diagnostic security; Diagnostic security; Secure software update and flash readiness; External interfaces; Secure software update and flash readiness (showing 12 of 19) |
| Impacted interfaces | External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface |
| Impacted security capabilities | Authentication; Diagnostic security; Secure communication |
| Impacted architecture elements | Application Software; Application Software; OEM/Customer Review Interface; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; Compliance Process; OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; Hardware Platform; Hardware Platform; OEM/Customer Review Interface; Security Services; Security Services; OEM/Customer Review Interface; System Core (showing 12 of 13) |
| Impacted work products | Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; Requirement traceability record; System/architecture design |
| Tools / IT / hardware / test | High/High/Low; High/High/Medium; Low/High/High; Low/High/Low; Low/High/Medium; Low/Low/High; Low/Low/Low; Low/Low/Medium; Medium/High/High; Medium/High/Low; Medium/High/Medium; Medium/Low/High (showing 12 of 14) |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Agree responsibility split (DIA) for the non-ECU portion.; Send linked open point to the customer for decision. |
Estimation / Resource / Tooling Impact
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/High/Low; High/High/Medium; Low/High/High; Low/High/Low; Low/High/Medium; Low/Low/High; Low/Low/Low; Low/Low/Medium; Medium/High/High; Medium/High/Low; Medium/High/Medium; Medium/Low/High (showing 12 of 14) |
Document Impact Diagram
Document Impact
Generated from document-specific requirement, traceability, SSR, and open-point evidence.
flowchart LR
doc["CVS123-2.pdf"]
d0["Authentication"]
doc --> d0
d1["Diagnostic security"]
doc --> d1
d2["Secure communication"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Secure software update and flash readiness"]
doc --> f1
f2["Feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability"]
doc --> f2
i0["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i0
i1["Interface: OEM/Customer Review Interface"]
doc --> i1
s0["SSR: SSR-BOOT-001"]
doc --> s0
s1["SSR: SSR-BOOT-002"]
doc --> s1
s2["SSR: SSR-BOOT-003"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-004"]
doc --> o1
o2["Open point: OP-008"]
doc --> o2
Mermaid source
flowchart LR
doc["CVS123-2.pdf"]
d0["Authentication"]
doc --> d0
d1["Diagnostic security"]
doc --> d1
d2["Secure communication"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Secure software update and flash readiness"]
doc --> f1
f2["Feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability"]
doc --> f2
i0["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i0
i1["Interface: OEM/Customer Review Interface"]
doc --> i1
s0["SSR: SSR-BOOT-001"]
doc --> s0
s1["SSR: SSR-BOOT-002"]
doc --> s1
s2["SSR: SSR-BOOT-003"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-004"]
doc --> o1
o2["Open point: OP-008"]
doc --> o2
Traceability
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| REQ-AUTO-00279 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00280 | SSR-SYS-009 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00281 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00282 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00283 | None | Needs Internal Review | n/a | Low confidence / human review before derivation. |
| REQ-AUTO-00284 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00285 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00286 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00287 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00288 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00289 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00290 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00291 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00292 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ_UDS-0051 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00294 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ_UDS-0051 | None | Duplicate / Merged | n/a | Duplicate of another requirement. |
| REQ-AUTO-00296 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00297 | SSR-UPD-002 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00298 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00299 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00300 | SSR-BOOT-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00301 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00302 | SSR-BOOT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00303 | SSR-BOOT-002 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00304 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00305 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00306 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00307 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00308 | SSR-BOOT-003 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00309 | SSR-DIAG-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00310 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00311 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00312 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00313 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00314 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00315 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00316 | SSR-BOOT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00317 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| REQ-AUTO-00318 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00319 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00320 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00321 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00322 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00323 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00324 | SSR-UPD-004 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00325 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00326 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00327 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00328 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00329 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00330 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00331 | SSR-BOOT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00332 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00333 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00334 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00335 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00336 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00337 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00338 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00339 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00340 | SSR-TOOL-001 | Shared Responsibility / CIA Needed | High | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00341 | SSR-SDT-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ_UDS-0051 | None | Duplicate / Merged | n/a | Duplicate of another requirement. |
| REQ-AUTO-00343 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00344 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00345 | SSR-LOG-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00346 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00347 | SSR-RBAC-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00348 | SSR-UPD-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00349 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00350 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00351 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00352 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00353 | SSR-TOOL-001 | Shared Responsibility / CIA Needed | High | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00354 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00355 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00356 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00357 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00358 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00359 | SSR-BOOT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00360 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00361 | SSR-BOOT-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00362 | SSR-BOOT-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00363 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00364 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00365 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00366 | SSR-UPD-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00367 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00368 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00369 | SSR-SYS-007 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00370 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00371 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00372 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00373 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00374 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00375 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00376 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00377 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00378 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00379 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00380 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00381 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00382 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00383 | SSR-VV-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00384 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00385 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00386 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00387 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00388 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00389 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00390 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00391 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00392 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00393 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00394 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00395 | SSR-SDT-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00396 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00397 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00398 | SSR-SDT-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00399 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00400 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00401 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00402 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00403 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00404 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00405 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00406 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00407 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00408 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00409 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00410 | SSR-COM-006 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00411 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00412 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00413 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00414 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00415 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00416 | SSR-DAI-004 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00417 | SSR-DIAG-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00418 | SSR-DIAG-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00419 | SSR-SYS-007 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00420 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00421 | SSR-BOOT-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00422 | SSR-SYS-008 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00423 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00424 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00425 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00426 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00427 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00428 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00429 | SSR-BOOT-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00430 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00431 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00432 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00433 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00434 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00435 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00436 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00437 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00438 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00439 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00440 | SSR-UPD-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00441 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00442 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00443 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00444 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00445 | SSR-TOOL-001 | Shared Responsibility / CIA Needed | High | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00446 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00447 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00448 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00449 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00450 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00451 | SSR-TOOL-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00452 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00453 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00454 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00455 | SSR-COM-007 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00456 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00457 | SSR-HW-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00458 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00459 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00460 | SSR-SYS-009 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00461 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00462 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00463 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00464 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00465 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00466 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00467 | SSR-COM-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00468 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00469 | SSR-UPD-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00470 | SSR-HW-001 | Shared Responsibility / CIA Needed | High | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00471 | SSR-VV-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00472 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00473 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00474 | SSR-SYS-008 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00475 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00476 | SSR-SYS-004 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00477 | SSR-SYS-005 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00478 | SSR-SYS-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00479 | SSR-SYS-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00480 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00481 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00482 | SSR-SDT-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00483 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ_UDS-0051 | None | Duplicate / Merged | n/a | Duplicate of another requirement. |
Detailed Evidence
Document intelligence markdown
CVS123-2
- Source PDF:
customer-input/pdf/CVS123-2.pdf - Converted Markdown:
converted/markdown/CVS123-2.md - Document type: Software Update Standard
- Domain: Hardware / Platform
- Confidence: High
- Evidence basis: Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis.
Executive Summary
Confirmed by requirements: this software update standard contributes 205 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; system architecture design; responsibility and customer approval model.
Confirmed by requirements: supplier positioning is 68 accept; 47 accept with assumption; 73 partially accept; 1 needs customer clarification; 1 needs internal review (showing 5 of 6). The generated traceability links this document to 31 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; system architecture design; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Document Abstract
| Field | Interpretation |
|---|---|
| Document Purpose | Confirmed by requirements: this software update standard contributes 205 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. |
| Engineering Interpretation | Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; system architecture design; responsibility and customer approval model. |
| Supplier Proposal Impact | Confirmed by requirements: supplier positioning is 68 accept; 47 accept with assumption; 73 partially accept; 1 needs customer clarification; 1 needs internal review (showing 5 of 6). The generated traceability links this document to 31 supplier system requirement records. |
| System / Security Impact | Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; system architecture design; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them. |
| Customer Clarification Impact | Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). Do not convert these items into agreed baseline scope until the customer confirms the decision. |
| Confidence and Limits | Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed. |
Main Requirement Themes
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 172 | REQ-AUTO-00279; REQ-AUTO-00280; REQ-AUTO-00281 |
| System architecture design | Groups related document requirements into a single engineering theme. | 130 | REQ-AUTO-00279; REQ-AUTO-00281; REQ-AUTO-00284 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 103 | REQ-AUTO-00279; REQ-AUTO-00280; REQ-AUTO-00282 |
| Software | Groups related document requirements into a single engineering theme. | 89 | REQ-AUTO-00279; REQ-AUTO-00284; REQ-AUTO-00286 |
| Application software | Groups related document requirements into a single engineering theme. | 84 | REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288 |
| Application software behavior | Groups related document requirements into a single engineering theme. | 84 | REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 80 | REQ-AUTO-00280; REQ-AUTO-00282; REQ-AUTO-00283 |
| Secure software update and bootloader | Defines ECU-side programming, boot/application state handling, integrity checks, and update evidence. | 67 | REQ-AUTO-00279; REQ-AUTO-00284; REQ-AUTO-00290 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 2 Overview | 4 | 1 | 1 | 2 |
| -- 2.1 Summary | 3 | 1 | 1 | 1 |
| -- 2.3 Relation to other specifications | 1 | 0 | 0 | 1 |
| 3 Terms, definitions and abbrevations | 12 | 0 | 0 | 3 |
| -- 3.1 Definitions of terms | 10 | 0 | 0 | 2 |
| -- 3.2 Abbreviated terms | 2 | 0 | 0 | 1 |
| 4 General requirements | 30 | 7 | 3 | 11 |
| -- 4.2 Software architecture requirements | 8 | 2 | 1 | 4 |
| -- 4.3 Software distribution requirements | 10 | 1 | 1 | 6 |
| 5 Detailed programming sequence | 19 | 11 | 2 | 11 |
| -- 5.1 Programming phase #1 – Download of application software and/or application data | 13 | 6 | 0 | 8 |
| -- -- 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming | 4 | 1 | 0 | 1 |
| -- -- 5.1.2 Programming step of phase #1 – Download of application software and data | 4 | 3 | 0 | 3 |
| -- -- 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network | 1 | 0 | 0 | 0 |
| -- -- 5.1.4 Programming Phase #2 | 4 | 2 | 0 | 4 |
| 6 Server reprogramming requirements | 29 | 7 | 2 | 10 |
| -- 6.1 Requirements for servers to support programming | 29 | 7 | 2 | 10 |
| -- -- 6.1.1 Boot software description and requirements | 14 | 4 | 2 | 7 |
| 7 Diagnostic service requirements | 29 | 18 | 1 | 7 |
| -- 7.1 RequestDownload (0x34) Service | 16 | 11 | 1 | 7 |
| -- -- 7.1.1 Request | 5 | 3 | 0 | 4 |
| -- -- 7.1.4 Service 0x34 Parameters | 6 | 5 | 0 | 3 |
| -- 7.2 TransferData (0x36) Service | 6 | 3 | 0 | 3 |
| -- -- 7.2.4 Service 0x36 Parameters | 6 | 3 | 0 | 3 |
| -- 7.4 SecuredDataTranmission (0x84) Service | 7 | 4 | 0 | 2 |
| -- -- 7.4.1 Request | 7 | 4 | 0 | 2 |
| 8 Diagnostic Routine Identifier Requirements | 49 | 22 | 2 | 15 |
| -- 8.1 Routine Session and routineControlSupport | 6 | 3 | 1 | 5 |
| -- -- 8.1.1 Routine Session Support | 6 | 3 | 1 | 5 |
| -- 8.2 Routine 0x2202 – Check Memory Block | 6 | 3 | 1 | 5 |
| -- -- 8.2.3 Negative Response | 2 | 0 | 0 | 2 |
| -- 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) | 12 | 3 | 1 | 8 |
| -- -- 8.3.2 Routine Positive Response | 2 | 0 | 0 | 1 |
| -- -- 8.3.4 Routine 0xFF00 Parameters | 4 | 1 | 1 | 4 |
| -- 8.4 Routine 0xFF01 – CheckProgrammingDependencies | 18 | 8 | 2 | 8 |
| -- -- 8.4.1 Request | 9 | 3 | 0 | 6 |
| -- -- 8.4.4 Routine 0xFF01 Parameters | 9 | 5 | 2 | 6 |
| -- 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) | 7 | 5 | 2 | 4 |
| -- -- 8.5.4 Routine 0xCAFE Parameters | 4 | 3 | 0 | 2 |
| 9 Software Verification and Encryption Requirements | 15 | 2 | 0 | 9 |
| -- 9.1 General Requirements on SDSC | 8 | 1 | 0 | 6 |
| -- -- 9.1.2 SDSC Sanity Check | 8 | 1 | 0 | 6 |
| -- 9.2 Software Verification | 7 | 1 | 0 | 5 |
| 10 Non-volatile server memory programming complete flow | 11 | 4 | 0 | 6 |
| 11 Normative references | 3 | 2 | 0 | 3 |
What this document does not confirm
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
Critical Requirements
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| REQ-AUTO-00317 | 95 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | 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. |
| REQ-AUTO-00282 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00299 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00310 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00333 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00334 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00350 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot. |
| REQ-AUTO-00377 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00411 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
| REQ-AUTO-00412 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 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. |
Open Points
| Open Point | Priority | Question | Impact | Status |
|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Open | |
| OP-004 | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Update-control scope and evidence ownership stay open; risk of an unprotected update path. | Open | |
| OP-008 | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Hardware fusing and EOL process design stay open; risk of an exposed debug/production interface. | Open |
Supplier System Requirements
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-BOOT-001 | Application software behavior — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Application software behavior and enforce the defined behaviour on verification failure. | REQ-AUTO-00300; REQ-AUTO-00302; REQ-AUTO-00316; REQ-AUTO-00331; REQ-AUTO-00359; REQ-AUTO-00429 | yes | Blocked by Customer Clarification |
| SSR-BOOT-002 | Hardware platform support — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Hardware platform support and enforce the defined behaviour on verification failure. | REQ-AUTO-00303; REQ-AUTO-00421 | yes | Candidate |
| SSR-BOOT-003 | System behavior — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for System behavior and enforce the defined behaviour on verification failure. | REQ-AUTO-00308; REQ-AUTO-00361; REQ-AUTO-00362 | yes | Candidate |
| SSR-COM-005 | Hardware platform support — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Hardware platform support, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00467 | yes | Candidate |
| SSR-COM-006 | Secure communication and freshness protection — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00410 | yes | Blocked by Customer Clarification |
| SSR-COM-007 | OEM/Customer Review Interface — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00455 | no | Ready for Customer Alignment |
| SSR-DAI-003 | Application software behavior — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Application software behavior data and reject manipulated or unauthenticated data. | REQ-AUTO-00321; REQ-AUTO-00339; REQ-AUTO-00414; REQ-AUTO-00435; REQ-AUTO-00436; REQ-AUTO-00441; REQ-AUTO-00473 | yes | Blocked by Customer Clarification |
| SSR-DAI-004 | Backend and IT integration — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Backend and IT integration data and reject manipulated or unauthenticated data. | REQ-AUTO-00409; REQ-AUTO-00416; REQ-AUTO-00437; REQ-AUTO-00446 | yes | Blocked by Customer Clarification |
| SSR-DIAG-003 | Backend and IT integration — Diagnostic Services | The ECU shall provide the diagnostic services for Backend and IT integration required by the allocated customer requirements, including the specified services, sessions and data identifiers. | REQ-AUTO-00309; REQ-AUTO-00417; REQ-AUTO-00418 | yes | Blocked by Customer Clarification |
| SSR-HW-001 | Hardware platform support — Hardware / HSM / Secure Storage | The ECU hardware shall provide the platform and secure-storage capabilities required for Hardware platform support. | REQ-AUTO-00457; REQ-AUTO-00470 | yes | Ready for Customer Alignment |
| SSR-LOG-002 | Hardware platform support — Security Logging and Event Handling | The ECU shall record bounded security-relevant events for Hardware platform support with sufficient integrity and context for diagnostics and incident evidence. | REQ-AUTO-00345 | no | Ready for Customer Alignment |
| SSR-RBAC-001 | Diagnostic security — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Diagnostic security, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00282; REQ-AUTO-00290; REQ-AUTO-00299; REQ-AUTO-00310; REQ-AUTO-00315; REQ-AUTO-00318; REQ-AUTO-00350; REQ-AUTO-00370; REQ-AUTO-00372; REQ-AUTO-00377; REQ-AUTO-00411; REQ-AUTO-00412; REQ-AUTO-00413; REQ-AUTO-00442; REQ-AUTO-00450 | yes | Blocked by Customer Clarification |
| SSR-RBAC-002 | Authentication — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00333; REQ-AUTO-00334 | yes | Blocked by Customer Clarification |
| SSR-RBAC-003 | Backend and IT integration — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00336 | yes | Blocked by Customer Clarification |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00347 | yes | Blocked by Customer Clarification |
| SSR-SDT-001 | Application software behavior — Secure Data Transfer / Data Security Container | The ECU shall protect security-relevant data transfer for Application software behavior using the agreed secured data transfer / data security container scheme. | REQ-AUTO-00341; REQ-AUTO-00380; REQ-AUTO-00395; REQ-AUTO-00398; REQ-AUTO-00415; REQ-AUTO-00423 | yes | Ready for Customer Alignment |
| SSR-SDT-002 | Hardware platform support — Secure Data Transfer / Data Security Container | The ECU shall protect security-relevant data transfer for Hardware platform support using the agreed secured data transfer / data security container scheme. | REQ-AUTO-00482 | no | Ready for Customer Alignment |
| SSR-SYS-004 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00281; REQ-AUTO-00301; REQ-AUTO-00305; REQ-AUTO-00314; REQ-AUTO-00328; REQ-AUTO-00354; REQ-AUTO-00355; REQ-AUTO-00356; REQ-AUTO-00368; REQ-AUTO-00371; REQ-AUTO-00428; REQ-AUTO-00433; REQ-AUTO-00444; REQ-AUTO-00458; REQ-AUTO-00476 | yes | Candidate |
| SSR-SYS-005 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00477; REQ-AUTO-00478; REQ-AUTO-00479 | yes | Blocked by Customer Clarification |
| SSR-SYS-007 | Application software behavior — System Function | The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00286; REQ-AUTO-00287; REQ-AUTO-00288; REQ-AUTO-00289; REQ-AUTO-00291; REQ-AUTO-00296; REQ-AUTO-00304; REQ-AUTO-00319; REQ-AUTO-00320; REQ-AUTO-00325; REQ-AUTO-00327; REQ-AUTO-00332; REQ-AUTO-00344; REQ-AUTO-00351; REQ-AUTO-00352; REQ-AUTO-00357; REQ-AUTO-00360; REQ-AUTO-00369; REQ-AUTO-00379; REQ-AUTO-00381; REQ-AUTO-00385; REQ-AUTO-00386; REQ-AUTO-00387; REQ-AUTO-00388; REQ-AUTO-00391; REQ-AUTO-00394; REQ-AUTO-00400; REQ-AUTO-00401; REQ-AUTO-00402; REQ-AUTO-00404; REQ-AUTO-00408; REQ-AUTO-00419 | yes | Ready for Customer Alignment |
| SSR-SYS-008 | Application software behavior — System Function | The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00422; REQ-AUTO-00427; REQ-AUTO-00432; REQ-AUTO-00459; REQ-AUTO-00461; REQ-AUTO-00465; REQ-AUTO-00468; REQ-AUTO-00472; REQ-AUTO-00474; REQ-AUTO-00475 | yes | Blocked by Customer Clarification |
| SSR-SYS-009 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00280; REQ-AUTO-00460 | yes | Candidate |
| SSR-TOOL-001 | Backend and IT integration — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration. | REQ-AUTO-00285; REQ-AUTO-00340; REQ-AUTO-00353; REQ-AUTO-00365; REQ-AUTO-00376; REQ-AUTO-00384; REQ-AUTO-00392; REQ-AUTO-00393; REQ-AUTO-00396; REQ-AUTO-00397; REQ-AUTO-00399; REQ-AUTO-00403; REQ-AUTO-00405; REQ-AUTO-00406; REQ-AUTO-00407; REQ-AUTO-00424; REQ-AUTO-00425; REQ-AUTO-00426; REQ-AUTO-00431; REQ-AUTO-00434; REQ-AUTO-00438; REQ-AUTO-00439; REQ-AUTO-00443; REQ-AUTO-00445; REQ-AUTO-00447; REQ-AUTO-00449; REQ-AUTO-00451 | yes | Ready for Customer Alignment |
| SSR-TOOL-002 | Backend and IT integration — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration. | REQ-AUTO-00452; REQ-AUTO-00453; REQ-AUTO-00454; REQ-AUTO-00456; REQ-AUTO-00462; REQ-AUTO-00463; REQ-AUTO-00466; REQ-AUTO-00483 | yes | Blocked by Customer Clarification |
| SSR-UPD-001 | System behavior — Software Update / Flashing | The ECU shall support secure software update/flashing for System behavior, accepting only authenticated, integrity-verified software through the agreed programming sequence. | REQ-AUTO-00307; REQ-AUTO-00322; REQ-AUTO-00323; REQ-AUTO-00329; REQ-AUTO-00330; REQ-AUTO-00364 | yes | Blocked by Customer Clarification |
| SSR-UPD-002 | Hardware platform support — Software Update / Flashing | The ECU shall support secure software update/flashing for Hardware platform support, accepting only authenticated, integrity-verified software through the agreed programming sequence. | REQ-AUTO-00297; REQ-AUTO-00349; REQ-AUTO-00481 | yes | Candidate |
| SSR-UPD-003 | Application software behavior — Software Update / Flashing | The ECU shall support secure software update/flashing for Application software behavior, accepting only authenticated, integrity-verified software through the agreed programming sequence. | REQ-AUTO-00306; REQ-AUTO-00311; REQ-AUTO-00312; REQ-AUTO-00313; REQ-AUTO-00326; REQ-AUTO-00346; REQ-AUTO-00358; REQ-AUTO-00363; REQ-AUTO-00367; REQ-AUTO-00373; REQ-AUTO-00374; REQ-AUTO-00375; REQ-AUTO-00382; REQ-AUTO-00430; REQ-AUTO-00448; REQ-AUTO-00469 | yes | Blocked by Customer Clarification |
| SSR-UPD-004 | External interfaces — Software Update / Flashing | The ECU shall support secure software update/flashing for External interfaces, accepting only authenticated, integrity-verified software through the agreed programming sequence. | REQ-AUTO-00324 | no | Candidate |
| SSR-UPD-005 | Backend and IT integration — Software Update / Flashing | The ECU shall support secure software update/flashing for Backend and IT integration, accepting only authenticated, integrity-verified software through the agreed programming sequence. | REQ-AUTO-00348; REQ-AUTO-00366; REQ-AUTO-00440 | yes | Blocked by Customer Clarification |
| SSR-VV-002 | Backend and IT integration — Verification and Validation | The supplier shall verify and validate Backend and IT integration per the agreed cybersecurity verification and validation plan. | REQ-AUTO-00383; REQ-AUTO-00471 | yes | Ready for Customer Alignment |
| SSR-VV-003 | Application software behavior — Verification and Validation | The supplier shall verify and validate Application software behavior per the agreed cybersecurity verification and validation plan. | REQ-AUTO-00389; REQ-AUTO-00390; REQ-AUTO-00464 | no | Ready for Customer Alignment |
Design Impact
- Impacted System Features: Application software behavior; Application software behavior; Secure software update and flash readiness; Application software behavior; Secure software update and flash readiness; Security evidence and traceability; Application software behavior; Security evidence and traceability; Application software behavior; System behavior; Secure software update and flash readiness; Authentication; Secure software update and flash readiness; Backend and IT integration; Backend and IT integration; Secure software update and flash readiness (showing 8 of 19)
- Impacted Interfaces: External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface
- Impacted Security Capabilities: Authentication; Diagnostic security; Secure communication
- Impacted Architecture Elements: Application Software; Application Software; OEM/Customer Review Interface; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; Compliance Process; OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; Hardware Platform (showing 8 of 13)
- Impacted Work Products: Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; Requirement traceability record; System/architecture design
- Impacted Tools It Hardware Test: High/High/Low; High/High/Medium; Low/High/High; Low/High/Low; Low/High/Medium; Low/Low/High; Low/Low/Low; Low/Low/Medium (showing 8 of 14)
- Impacted Supplier System Requirements: SSR-BOOT-001; SSR-BOOT-002; SSR-BOOT-003; SSR-COM-005; SSR-COM-006; SSR-COM-007; SSR-DAI-003; SSR-DAI-004 (showing 8 of 31)
- Design Assumptions Introduced: Security-relevant requirement the ECU can own once responsibility/method is confirmed.
- Design Decisions Required: Agree responsibility split (DIA) for the non-ECU portion.; Send linked open point to the customer for decision.