CVS123-2.pdf · Software Update Standard · Hardware / Platform
CVS123-2.pdf · Software Update Standard · Hardware / Platform
Systems-engineering read of what this document defines for the system - scope, boundaries, interfaces, obligations, and what is still open.
Scope: this software update standard specifies system architecture design, covering 2 Overview; 2.1 Summary; 2.3 Relation to other specifications; 3 Terms, definitions and abbrevations; 3.1 Definitions of terms; 3.3 Naming conventions.
System boundary and interfaces: the document constrains 2 interface(s) - OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; principal functions in scope are Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection.
Design and security impact: affects Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection; security capabilities touched: Diagnostic security; Authentication; Cybersecurity requirement handling; 29 supplier system requirement(s) were derived from this document.
Open for the customer: 6 document-linked open point(s) - mainly Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).; 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. (sample: 3 of 6) - plus 18 unidentified requirement-like statement(s). Do not baseline these until the customer confirms.
Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used.
| Theme | Engineering Meaning | Requirement Count | Representative Requirements |
|---|---|---|---|
| System architecture design | Groups related document requirements into a single engineering theme. | 252 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0003; RFQX-CVS123-2-0004 |
| Requirement | Groups related document requirements into a single engineering theme. | 178 | RFQX-CVS123-2-0026; RFQX-CVS123-2-0028; RFQX-CVS123-2-0034 |
| Software | Groups related document requirements into a single engineering theme. | 145 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0004; RFQX-CVS123-2-0005 |
| Information | Groups related document requirements into a single engineering theme. | 138 | RFQX-CVS123-2-0004; RFQX-CVS123-2-0005; RFQX-CVS123-2-0006 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 127 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0002; RFQX-CVS123-2-0005 |
| Secure software update and bootloader | Defines ECU-side programming, boot/application state handling, integrity checks, and update evidence. | 114 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0004; RFQX-CVS123-2-0006 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 112 | RFQX-CVS123-2-0002; RFQX-CVS123-2-0007; RFQX-CVS123-2-0009 |
| Diagnostics and service access | Defines UDS service behavior, authorization expectations, safe-state checks, and diagnostic evidence. | 96 | RFQX-CVS123-2-0006; RFQX-CVS123-2-0009; RFQX-CVS123-2-0010 |
| Section | Requirements | Information | Unknown / Review Needed | Total Items | Critical | Open Points | SSR Links |
|---|---|---|---|---|---|---|---|
| 2 Overview | 0 | 13 | 0 | 14 | 1 | 1 | 0 |
| -- 2.1 Summary | 0 | 10 | 0 | 10 | 0 | 0 | 0 |
| -- 2.3 Relation to other specifications | 0 | 3 | 0 | 4 | 1 | 1 | 0 |
| 3 Terms, definitions and abbrevations | 2 | 3 | 0 | 16 | 8 | 4 | 0 |
| -- 3.1 Definitions of terms | 2 | 1 | 0 | 12 | 7 | 3 | 0 |
| -- 3.2 Abbreviated terms | 0 | 0 | 0 | 2 | 1 | 1 | 0 |
| -- 3.3 Naming conventions | 0 | 2 | 0 | 2 | 0 | 0 | 0 |
| 4 General requirements | 24 | 7 | 0 | 36 | 12 | 4 | 11 |
| -- 4.2 Software architecture requirements | 6 | 2 | 0 | 9 | 3 | 2 | 4 |
| -- 4.3 Software distribution requirements | 8 | 4 | 0 | 13 | 2 | 2 | 3 |
| 5 Detailed programming sequence | 13 | 79 | 0 | 94 | 9 | 3 | 6 |
| -- 5.1 Programming phase #1 – Download of application software and/or application data | 8 | 74 | 0 | 83 | 4 | 1 | 3 |
| -- -- 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming | 0 | 28 | 0 | 28 | 0 | 0 | 0 |
| -- -- 5.1.2 Programming step of phase #1 – Download of application software and data | 7 | 28 | 0 | 35 | 3 | 0 | 3 |
| -- -- 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network | 0 | 6 | 0 | 6 | 0 | 0 | 0 |
| -- -- 5.1.4 Programming Phase #2 | 1 | 12 | 0 | 14 | 1 | 1 | 0 |
| 6 Server reprogramming requirements | 28 | 6 | 0 | 37 | 10 | 3 | 12 |
| -- 6.1 Requirements for servers to support programming | 28 | 6 | 0 | 37 | 10 | 3 | 12 |
| -- -- 6.1.1 Boot software description and requirements | 13 | 3 | 0 | 17 | 5 | 3 | 8 |
| 7 Diagnostic service requirements | 29 | 5 | 0 | 35 | 18 | 1 | 7 |
| -- 7.1 RequestDownload (0x34) Service | 14 | 5 | 0 | 20 | 12 | 1 | 7 |
| -- -- 7.1.1 Request | 4 | 3 | 0 | 8 | 4 | 1 | 4 |
| -- -- 7.1.4 Service 0x34 Parameters | 6 | 1 | 0 | 7 | 5 | 0 | 3 |
| -- 7.2 TransferData (0x36) Service | 7 | 0 | 0 | 7 | 3 | 0 | 2 |
| -- -- 7.2.4 Service 0x36 Parameters | 7 | 0 | 0 | 7 | 3 | 0 | 2 |
| -- 7.4 SecuredDataTranmission (0x84) Service | 8 | 0 | 0 | 8 | 3 | 0 | 2 |
| -- -- 7.4.1 Request | 8 | 0 | 0 | 8 | 3 | 0 | 2 |
| 8 Diagnostic Routine Identifier Requirements | 62 | 12 | 0 | 76 | 21 | 2 | 16 |
| -- 8.1 Routine Session and routineControlSupport | 7 | 0 | 0 | 7 | 3 | 1 | 5 |
| -- -- 8.1.1 Routine Session Support | 7 | 0 | 0 | 7 | 3 | 1 | 5 |
| -- 8.2 Routine 0x2202 – Check Memory Block | 8 | 2 | 0 | 10 | 3 | 1 | 6 |
| -- -- 8.2.3 Negative Response | 3 | 1 | 0 | 4 | 0 | 0 | 2 |
| -- 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) | 14 | 3 | 0 | 17 | 3 | 0 | 6 |
| -- -- 8.3.2 Routine Positive Response | 2 | 0 | 0 | 2 | 0 | 0 | 1 |
| -- -- 8.3.4 Routine 0xFF00 Parameters | 6 | 0 | 0 | 6 | 1 | 0 | 4 |
| -- 8.4 Routine 0xFF01 – CheckProgrammingDependencies | 21 | 6 | 0 | 29 | 8 | 2 | 6 |
| -- -- 8.4.1 Request | 8 | 3 | 0 | 12 | 4 | 1 | 5 |
| -- -- 8.4.4 Routine 0xFF01 Parameters | 13 | 3 | 0 | 17 | 4 | 1 | 4 |
| -- 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) | 12 | 1 | 0 | 13 | 4 | 1 | 3 |
| -- -- 8.5.4 Routine 0xCAFE Parameters | 5 | 0 | 0 | 5 | 2 | 0 | 1 |
| 9 Software Verification and Encryption Requirements | 12 | 9 | 0 | 22 | 2 | 1 | 8 |
| -- 9.1 General Requirements on SDSC | 6 | 5 | 0 | 12 | 1 | 1 | 5 |
| -- -- 9.1.2 SDSC Sanity Check | 6 | 5 | 0 | 12 | 1 | 1 | 5 |
| -- 9.2 Software Verification | 6 | 4 | 0 | 10 | 1 | 0 | 5 |
| 10 Non-volatile server memory programming complete flow | 8 | 4 | 0 | 13 | 4 | 1 | 5 |
| 11 Normative references | 0 | 0 | 0 | 5 | 3 | 2 | 1 |
Tables are reconstructed column-correct from the document text layer (no OCR). Diagrams are linked from converted image assets.
| Term | Definition |
|---|---|
| Adaptive data | A data set that controls the system behaviour depending on the installation environment. Contains a variant-specific set of parameter values that is required for correct |
| Application data | operation of the control unit in a specific vehicle variant. |
| module | It must be clearly separated from the application software. For this reason, it is |
| (Calibration data) | located in a separate memory area and must also be erasable and programmable independently of the application software. |
| Application software | Contains all vehicle functions required for the normal server operation. If valid |
| module | Application software is programmed, the server will activate the application software after the start-up phase by starting the operating system. The application software is programmable by an external programming tool. |
| Boot loader | Equivalent with reprogramming software in (1) Contains the boot software which is used for the booting and reprogramming of the |
| Boot software | ECU via diagnostic protocol (e.g., UDS on CAN). The software is located in a |
| Term | Definition |
|---|---|
| Adaptive data | A data set that controls the system behaviour depending on the installation environment. Contains a variant-specific set of parameter values that is required for correct |
| Application data | operation of the control unit in a specific vehicle variant. |
| module | It must be clearly separated from the application software. For this reason, it is |
| (Calibration data) | located in a separate memory area and must also be erasable and programmable independently of the application software. |
| Application software | Contains all vehicle functions required for the normal server operation. If valid |
| module | Application software is programmed, the server will activate the application software after the start-up phase by starting the operating system. The application software is programmable by an external programming tool. |
| Boot loader | Equivalent with reprogramming software in (1) Contains the boot software which is used for the booting and reprogramming of the |
| Boot software | ECU via diagnostic protocol (e.g., UDS on CAN). The software is located in a |
| module | protected area of the ECU flash memory. All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating |
| (Boot loader and | system, start-up code, low level flash routines (for erasing, writing, reading), |
| Boot manager) | EEPROM access routines (read, write functionality), software compatibility checks etc. shall be implemented in the boot software code. Also referred to as “application valid” flag. Variable holding information about whether or not the software modules installed on the ECU are consistent and executable. |
| C1 | 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. More information on CVS124 REQ_UDS 0051 Also referred to as “programming request” flag. Variable holding information about whether or not there is a pending programming request from client. |
| C2 | 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. More information on CVS124 REQ_UDS 0051 Also referred to as “reprogrammed” flag. Variable holding information about whether or not the ECU has been |
| C3 | reprogrammed after the application was used the last time. The value of this variable may be used by the application to determine whether or not initialization is required. |
Diagnostic parameter or service behavior
| Term | Definition Component of the software to be installed which identity (e.g., part number and |
|---|---|
| Module | version) can be obtained via UDS service ReadDataByIdentifier, e.g., boot loader, application software, application data. Data collected or calculated during the operation of an ECU, used to obtain an |
| Operational data | understanding of the product’s current condition or of how the product has been used. |
| Satisfied | A programming precondition agreed between supplier and vehicle manufacturer |
| programming | which, together with other agreed programming preconditions, shall be fulfilled |
| precondition | before an ECU is made eligible for programming. |
| Server | Function that is part of an electronic control unit and that provides the diagnostic services defined in (1) |
| Standalone (server) | Server which is not yet connected to the vehicle network |
| SW area | An allocation in memory with start and end address to which a software module is allocated. System that controls functions such as test, inspection, monitoring, or diagnosis of |
| Term | Definition Component of the software to be installed which identity (e.g., part number and |
|---|---|
| Module | version) can be obtained via UDS service ReadDataByIdentifier, e.g., boot loader, application software, application data. Data collected or calculated during the operation of an ECU, used to obtain an |
| Operational data | understanding of the product’s current condition or of how the product has been used. |
| Satisfied | A programming precondition agreed between supplier and vehicle manufacturer |
| programming | which, together with other agreed programming preconditions, shall be fulfilled |
| precondition | before an ECU is made eligible for programming. |
| Server | Function that is part of an electronic control unit and that provides the diagnostic services defined in (1) |
| Standalone (server) | Server which is not yet connected to the vehicle network |
| SW area | An allocation in memory with start and end address to which a software module is allocated. System that controls functions such as test, inspection, monitoring, or diagnosis of |
| Tester | 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) |
Diagnostic parameter or service behavior
Wide table - scrolls horizontally inside this card.
| Service according to (1) | Addressing mode | Application Sessions Def | Non-Def Ext | Boot loader Sessions Def | Non-Def Prg | Ext |
|---|---|---|---|---|---|---|
| RequestDownload (0x34) | P | - | - | - | M | - |
| TransferData (0x36) | P | - | - | - | M | - |
| RequestTransferExit (0x37) | P | - | - | - | M | - |
| SecuredDataTranmission (0x84) | P | M | M | M | M | M |
Diagnostic parameter or service behavior
| Byte | Description |
|---|---|
| Value | |
| 0x2202 | checkMemory This routineIdentifier allows the client to start a check routine of the server. |
| 0xCAFE | Entity Management Protocol This routineIdentifier enables the client to query/update the cyber security entities. |
| 0xFF00 | eraseMemory This routineIdentifier allows the client to start an erase routine of the server. checkProgrammingDependencies |
| 0xFF01 | This routineIdentifier allows the client to start a server check routine, in order to check the consistency of the server. |
Diagnostic parameter or service behavior
| Byte No. | Description | Cvt | Byte Value |
|---|---|---|---|
| 1 | RequestDownload Request SID | M | 0x34 |
| 2 | dataFormatIdentifier | M | 0x00 – 0xFF |
| 3 | addressAndLengthFormatIdentifier memoryAddress byte 1 (MSB) byte 2 | M | 0x33 or 0x44 |
| 4 .. (m- | byte 3 | M | 0x00 – 0xFF |
| 1)+4 | byte 4 : User Optional byte 5 : not available .. byte m : not available memorySize byte 1 (MSB) byte 2 | ||
| n -(k-1) .. | byte 3 | 0x00 – 0xFF | |
| n | byte 4 :Mandatory if Memory address byte 4 is used byte 5 : not available .. byte m : not available | M |
Software update or memory programming context
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RequestDownload Response SID | M | 0x74 |
| #2 | lengthFormatIdentifier maxNumberOfBlockLength[] = [ | M | 0x20 0x0000 – |
| #3.. #4 | byte #1 (MSB) byte #2 ] | M | 0xFFFF |
Software update or memory programming context
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RequestDownload Response SID | M | 0x74 |
| #2 | lengthFormatIdentifier maxNumberOfBlockLength[] = [ | M | 0x20 0x0000 – |
| #3.. #4 | byte #1 (MSB) byte #2 ] | M | 0xFFFF |
Table source context
| 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 |
Software update or memory programming context
| 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 |
Table source context
| Byte No | Description | Cvt | Byte Value |
|---|---|---|---|
| 1 | RequestTransferExit Request SID | M | 0x37 |
Table source context
| Byte No | Description | Cvt | Byte Value |
|---|---|---|---|
| 1 | RequestTransferExit Request SID | M | 0x37 |
Table source context
Wide table - scrolls horizontally inside this card.
| RID | Name | Application Sessions Def | Non-Def Ext | Boot Sessions Def | loader Non-Def Prg | Ext |
|---|---|---|---|---|---|---|
| 0x2202 | Check Memory Block | - | - | - | M | - |
| 0xFF00 | EraseMemory | - | - | - | M | - |
| 0xFF01 | CheckProgrammingDependencies | - | M | - | M | M |
| 0xCAFE | Entity Management Protocol (EMP) | M | M | M | M | M |
Diagnostic parameter or service behavior
Wide table - scrolls horizontally inside this card.
| RID | Name | startRoutine (0x01) | routineControlType stopRoutine (0x02) | requestRoutineResults (0x03) |
|---|---|---|---|---|
| 0x2202 | Check Memory Block | M | - | - |
| 0xFF00 | EraseMemory | M | - | - |
| 0xFF01 | CheckProgrammingDependencies | M | - | - |
| 0xCAFE | Entity Management Protocol (EMP) | M | - | - |
Diagnostic parameter or service behavior
Wide table - scrolls horizontally inside this card.
| RID | Name | startRoutine (0x01) | routineControlType stopRoutine (0x02) | requestRoutineResults (0x03) |
|---|---|---|---|---|
| 0x2202 | Check Memory Block | M | - | - |
| 0xFF00 | EraseMemory | M | - | - |
| 0xFF01 | CheckProgrammingDependencies | M | - | - |
| 0xCAFE | Entity Management Protocol (EMP) | M | - | - |
Diagnostic parameter or service behavior
| 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 |
Diagnostic parameter or service behavior
| 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 |
Diagnostic parameter or service behavior
| Hex | Description | Cvt |
|---|---|---|
| 0x00 | correctResult | M |
| 0x01 | incorrectResult | M |
Diagnostic parameter or service behavior
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RoutineControl Request SID | M | 0x31 |
| #2 | routineControlType (StartRoutine) | M | 0x01 |
| #3 | routineIdentifier (MSB) | M | 0xFF |
| #4 | routineIdentifier (LSB) addressAndLengthFormatIdentifier (XXXXYYYYb) | M | 0x00 |
| #5 | XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. | M | 0x00 – 0xFF |
| #6 | memoryStartAddress[] = [ | ||
| : | byte#1 (MSB) | C1 | 0x00 – 0xFF |
| #(m-1)+6 | : byte#m ] | : C1 | : 0x00 – 0xFF |
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RoutineControl Request SID | M | 0x31 |
| #2 | routineControlType (StartRoutine) | M | 0x01 |
| #3 | routineIdentifier (MSB) | M | 0xFF |
| #4 | routineIdentifier (LSB) addressAndLengthFormatIdentifier (XXXXYYYYb) | M | 0x00 |
| #5 | XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. | M | 0x00 – 0xFF |
| #6 | memoryStartAddress[] = [ | ||
| : | byte#1 (MSB) | C1 | 0x00 – 0xFF |
| #(m-1)+6 | : byte#m ] | : C1 | : 0x00 – 0xFF |
| #n-(k-1) | memorySize[] = [ | ||
| : | byte#1 (MSB) | C2 | 0x00 – 0xFF |
| #n | : byte#k ] | : C2 | : 0x00 – 0xFF |
Diagnostic parameter or service behavior
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RoutineControl Request SID | M | 0x31 |
| #2 | routineControlType (StartRoutine) | M | 0x01 |
| #3 | routineIdentifier (MSB) | M | 0xFF |
| #4 | routineIdentifier (LSB) addressAndLengthFormatIdentifier (XXXXYYYYb) | M | 0x00 |
| #5 | XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. | M | 0x00 – 0xFF |
| #6 | memoryStartAddress[] = [ | ||
| : | byte#1 (MSB) | C1 | 0x00 – 0xFF |
| #(m-1)+6 | : byte#m ] | : C1 | : 0x00 – 0xFF |
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #1 | RoutineControl Request SID | M | 0x31 |
| #2 | routineControlType (StartRoutine) | M | 0x01 |
| #3 | routineIdentifier (MSB) | M | 0xFF |
| #4 | routineIdentifier (LSB) addressAndLengthFormatIdentifier (XXXXYYYYb) | M | 0x00 |
| #5 | XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. | M | 0x00 – 0xFF |
| #6 | memoryStartAddress[] = [ | ||
| : | byte#1 (MSB) | C1 | 0x00 – 0xFF |
| #(m-1)+6 | : byte#m ] | : C1 | : 0x00 – 0xFF |
| #n-(k-1) | memorySize[] = [ | ||
| : | byte#1 (MSB) | C2 | 0x00 – 0xFF |
| #n | : byte#k ] | : C2 | : 0x00 – 0xFF |
Diagnostic parameter or service behavior
| Byte Value Description | Cvt | |
|---|---|---|
| 0x00 Automatic | erase: Erase is performed by boot loader automatically when | C |
| RequestDownload | is received for each Flash sector in the module. | |
| Module | erase: memoryStartAddress byte is used for module index. | |
| 0x01 memorySize | parameter is not used. | M |
| E.g., | 02, Module 2 (Application SW module) | |
| 0x02 – 0xFF Physical | memory range erase: Refer to ISO 14229-1 Table H1 | M |
Diagnostic parameter or service behavior
| Hex | Description When addressAndLengthFormatIdentifier = 0x00: | Cvt |
|---|---|---|
| 0x00 | Erasing will be initiated when RequestDownload service is requested. When addressAndLengthFormatIdentifier > 0x00: Erase operation was completed successfully. | M |
| 0x01 | Erase operation was unsuccessful. | M |
State-machine or transition behavior
| Byte Value Description | Cvt | |
|---|---|---|
| 0x00 Automatic | erase: Erase is performed by boot loader automatically when | C |
| RequestDownload | is received for each Flash sector in the module. | |
| Module | erase: memoryStartAddress byte is used for module index. | |
| 0x01 memorySize | parameter is not used. | M |
| E.g., | 02, Module 2 (Application SW module) | |
| 0x02 – 0xFF Physical | memory range erase: Refer to ISO 14229-1 Table H1 | M |
Diagnostic parameter or service behavior
| Byte | Description | Cvt | Hex |
|---|---|---|---|
| #1 | RoutineControl Request SID | M | 0x31 |
| #2 | routineControlType (StartRoutine) | M | 0x01 |
| #3 | routineIdentifier (MSB) | M | 0xFF |
| #4 | routineIdentifier (LSB) | M | 0x01 |
Diagnostic parameter or service behavior
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #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[] |
Diagnostic parameter or service behavior
| Byte | Description | Cvt | Byte Value |
|---|---|---|---|
| #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[] |
Diagnostic parameter or service behavior
| 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 |
Diagnostic parameter or service behavior
| 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 |
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Diagnostic parameter or service behavior
Software update or memory programming context
Diagnostic parameter or service behavior
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
Security protocol or cryptographic context
| Field | Value |
|---|---|
| Source PDF | CVS123-2.pdf |
| Document Type | Software Update Standard |
| Domain | Hardware / Platform |
| Scope Summary | 178 confirmed requirements, 18 needing clarification, 138 information, 4 reference items; 29 linked SSRs; 6 linked open points. |
| Main Themes | System architecture design; Requirement; Software; Information; Responsibility and customer approval model (sample: 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. |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| RFQX-CVS123-2-0286 | 95 | High risk due to unclear OEM/supplier responsibility | 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 providedsecurity relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0023 | 95 | High risk due to unclear OEM/supplier responsibility | 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. shall be implemented in the boot software code. 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. It must be clearly separated from the application software. For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. Application software module Contains all vehicle functions required for the normal server operation. The value of this variable may be used by the application to determine whether or not initialization is required. 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. 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; High estimation impact; blocks SSR derivation | Reference / Document Information |
| RFQX-CVS123-2-0035 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0053 | 81 | High risk due to unclear OEM/supplier responsibility | When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0075 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0153 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0182 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0183 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0206 | 81 | High risk due to unclear OEM/supplier responsibility | (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0322 | 81 | High risk due to unclear OEM/supplier responsibility | 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.security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Needs Customer Clarification |
| RFQX-CVS123-2-0030 | 81 | High risk due to unclear OEM/supplier responsibility | 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. 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 memorysecurity relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Reference / Document Information |
| 00930000 | 81 | High risk due to unclear OEM/supplier responsibility | 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). 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. #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. #008AFFFF # #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB Figure 8 – Memory layoutsecurity relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | Reference / Document Information |
Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).
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).
Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.
Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.
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-001 | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).TARA scope and effort stay open; downstream assets, goals and design may rework. | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | Proceed on the working ECA-ECU interpretation; flag every TARA-scope statement as assumption until confirmed. | OEM / Customer | Open | |
| 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 | |
| OP-009 | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case. | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Deliver supplier-owned work products per concept; require a signed DIA/RASIC before treating shared items as supplier scope. | OEM / Customer + Supplier (DIA) | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Decide whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context. | Carry the items as customer-confirmation dependencies and review them in the next clarification workshop. | OEM / Customer | Open |
Items carrying a customer requirement ID and a normative (shall/must) statement.
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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. Details & reviewer feedbackSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None Security capability Authentication Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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. Details & reviewer feedbackSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None Security capability Authentication Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
A server that is running in the application shall respond with the same diagnostic address after a switch to boot. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
The server shall support the routine in the diagnosticSession according to Table 12. Details & reviewer feedbackSection 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support Page page 29 Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. Details & reviewer feedbackSection 8.2 Routine 0x2202 – Check Memory Block Page page 30 Feature / Interface Secure software update and flash readiness / None Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: • Routine 0xFF00 Erase Memory Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Security capability Diagnostic security Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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). Details & reviewer feedbackSection 4.2 Software architecture requirements Page page 10 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
Programmable servers shall support the full programming sequence described in this chapter. Details & reviewer feedbackSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). Details & reviewer feedbackSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements Page page 22 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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). Details & reviewer feedbackSection 6.1.1.4 Performance requirements Page page 23 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
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). Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 23 Feature / Interface Secure software update and flash readiness / None Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server shall be able to update an individual module independently from any other module. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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. Details & reviewer feedbackSection 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service Page page 24 Security capability Cybersecurity requirement handling Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support the routineControlType according to Table 13. Details & reviewer feedbackSection Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support Page page 30 Security capability Cybersecurity requirement handling Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support parameter routineStatus routineResult formatted according to Table 22. Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
The integrity information shall be supplied to the server before the software is updated. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall sign the hashed output using the receipt-keys. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client shall send the Servers routineStatus routineResult response to the backend. Details & reviewer feedbackSection Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification Page page 38 Feature / Interface Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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). Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. Details & reviewer feedbackSection 6 Server reprogramming requirements 6.1 Requirements for servers to support programming Page page 21 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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). Details & reviewer feedbackSection 7.1 RequestDownload (0x34) Service Page page 24 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24 Details & reviewer feedbackSection 7.1 RequestDownload (0x34) Service Page page 24 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. Details & reviewer feedbackSection 7.1.1 Request Page page 25 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
The server shall not execute the new software until it can be verified using routine 0xFF01. Details & reviewer feedbackSection 7.1.1 Request Page page 25 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support service request formatted according to Table 5. Details & reviewer feedbackSection 7.1.1 Request Page page 25 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support service positive response formatted according to Table 6. Details & reviewer feedbackSection 7.1.2 Positive Response Page page 26 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support service negative response as per ISO14229-1:2020. Details & reviewer feedbackSection #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response Page page 26 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. Details & reviewer feedbackSection 7.1.4 Service 0x34 Parameters Page page 26 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. Details & reviewer feedbackSection 7.1.4 Service 0x34 Parameters Page page 26 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall verify the software hash after decryption and/or decompression are performed. Details & reviewer feedbackSection 7.1.4 Service 0x34 Parameters Page page 26 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier The server shall support parameter lengthFormatIdentifier formatted according to Table 9. Details & reviewer feedbackSection 7.2.4 Service 0x36 Parameters Page page 27 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
The server shall support request formatted according to ISO14229-1:2020. Details & reviewer feedbackSection M 0 7.2 TransferData (0x36) Service 7.2.1 Request Page page 27 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter Page page 27 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support request formatted according to Table 10. Details & reviewer feedbackSection 7.3 RequestTransferExit (0x37) Service 7.3.1 Request Page page 28 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support positive response formatted according to Table 11. Details & reviewer feedbackSection Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response Page page 28 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support service 0x84 according to CVS32. Details & reviewer feedbackSection 7.4 SecuredDataTranmission (0x84) Service Page page 28 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter Page page 29 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. Details & reviewer feedbackSection 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) Page page 29 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 8.2 Routine 0x2202 – Check Memory Block Page page 30 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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). Details & reviewer feedbackSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
The server shall verify the integrity of the software as a part of the consistency check. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The integrity check shall be carried out solely by the server. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 36 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall use ED25519 as signature algorithm. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response The server shall support the routine positive response according to Table 27. Details & reviewer feedbackSection 8.5.4 Routine 0xCAFE Parameters Page page 39 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support the parameter EMP message according to CVS33. Details & reviewer feedbackSection 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message Page page 39 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall validate each VerificationEntry found in the SDSC. Details & reviewer feedbackSection 9.2 Software Verification Page page 41 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
The server shall be able to verify that erased-only blocks covered in range of memory are erased. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
If OK is returned, the server shall accept that installed software is valid in terms of integrity. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. |
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”. Details & reviewer feedbackSection 4.2 Software architecture requirements Page page 10 Security capability Diagnostic security Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197 Details & reviewer feedbackSection 4.2 Software architecture requirements Page page 10 Security capability Diagnostic security Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The supplier shall deliver the necessary information to verify the integrity of the flash files. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Diagnostic services support shall be as per CVS124. Details & reviewer feedbackSection 6.1.1.2 Boot software session requirements Page page 22 Security capability Diagnostic security Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
ECU identification data support shall be as per CVS124. Details & reviewer feedbackSection Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data Page page 23 Security capability Cybersecurity requirement handling Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 7.1 RequestDownload (0x34) Service Page page 24 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection Figure 6: Erased-only bytes of a memory module Page page 41 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
, the client post physically addressed authentication (0x29) request with subfunction deAuthenticate (0x00) based on CVS31 with SPRMIB not set. Details & reviewer feedbackSection 5.1.4 Programming Phase #2 Page page 20 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
prevents the scenario of erasing the copied bootloader while boot loader update and leaving the ECU without any bootloader. Details & reviewer feedbackSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. Details & reviewer feedbackSection 4 General requirements Page page 9 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 4.2 Software architecture requirements Page page 10 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 4.1 Documentation requirements Page page 10 Feature / Interface Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The supplier shall document the versioning concept for supplier specific DIDs. Details & reviewer feedbackSection 4.2 Software architecture requirements Page page 10 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
cannot be met, a compression method shall be implemented. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Additionally, the services specified in Table 3 shall be supported. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. Details & reviewer feedbackSection 8.2 Routine 0x2202 – Check Memory Block Page page 30 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
This RoutineIdentifier shall be able to execute independent from programming sequence Details & reviewer feedbackSection 8.4.1 Request Page page 35 Feature / Interface Secure software update and flash readiness / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. Details & reviewer feedbackSection 9.1.2 SDSC Sanity Check Page page 40 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
C2 Also referred to as “programming request” flag. Details & reviewer feedbackSection More information on CVS124 Page page 6 Feature / Interface Secure software update and flash readiness / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
C3 Also referred to as “reprogrammed” flag. Details & reviewer feedbackSection More information on CVS124 Page page 6 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
A joint use of program code for communication functions (com stack) by the application and the boot loader is not permitted. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
) before the erase process starts, to ensure that the server will start in boot loader mode if the programming gets interrupted or if the programming is faulty. Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Feature / Interface Secure software update and flash readiness / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
, this routineIdentifier allows the server to verify if the transferred data is correct (has not been corrupted) by calculating a checksum and comparing this checksum with the checksum transferred as part of the data (via transferData). Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
, as a part of the consistency check the server verifies the integrity of the programmed software. Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
, the check on consistency can produce a positive result only if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. Details & reviewer feedbackSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 Feature / Interface Security evidence and traceability / None Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord Details & reviewer feedbackSection 7.4.1 Request Page page 28 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
• Service 0x34 RequestDownload Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
• Service 0x36 TransferData Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
• Service 0x37 RequestTransferExit 8.4.4.2 Parameter routineResultProofLength Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
SDSC is transmitted via EMP, see chapter 9. Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
• Service 0x34 RequestDownload Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 1
|
• Service 0x36 TransferData Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
• Service 0x37 RequestTransferExit Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). Details & reviewer feedbackSection 4 General requirements Page page 9 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. Details & reviewer feedbackSection 4.3 Software distribution requirements Page page 11 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Application software and application data modules shall be programmable in any order. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
It shall be possible to program the same software version repeatedly. Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The server shall support the routines specified in Table 4. Details & reviewer feedbackSection 6.1.1.4.1 Server routine access Page page 23 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. Details & reviewer feedbackSection 7.1.1 Request Page page 25 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support parameter dataFormatIdentifier formatted according to Table 7. Details & reviewer feedbackSection 7.1.4.1 Parameter dataFormatIdentifier Page page 26 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. Details & reviewer feedbackSection 7.1.4.2 Parameter addressAndLengthFormatIdentifier Page page 27 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
The server shall support positive response formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.2.2 Positive Response Page page 27 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
If for any reason an error occurs during decryption of data, the server shall return NRC 0x10. Details & reviewer feedbackSection 7.2.4 Service 0x36 Parameters Page page 27 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.2.4.2 Parameter transferRequestParameterRecord Page page 28 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall not support transferRequestParameterRecord parameter. Details & reviewer feedbackSection 7.4.1 Request Page page 28 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall not support transferResponseParameterRecord parameter. Details & reviewer feedbackSection 7.3.4.2 Parameter transferResponseParameterRecord Page page 28 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support request formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.4.1 Request Page page 28 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support positive response formatted according to ISO14229-1:2020. Details & reviewer feedbackSection 7.4.2 Positive Response Page page 29 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The server shall support negative response codes according to CVS32. Details & reviewer feedbackSection 8.1.1 Routine Session Support Page page 29 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. Details & reviewer feedbackSection 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) Page page 29 Feature / Interface Secure communication and freshness protection / None Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support the routine request according to Table 15. Details & reviewer feedbackSection 8.2.3 Negative Response Page page 31 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response The server shall support the routine positive response according to Table 16. Details & reviewer feedbackSection 8.2.3 Negative Response Page page 31 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support parameter routineStatus routineResult formatted according to Table 17. Details & reviewer feedbackSection 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult Page page 32 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support the routine request according to Table 18. Details & reviewer feedbackSection 8.3.1 Routine Request Page page 33 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support the routine positive response according to Table 19. Details & reviewer feedbackSection 8.3.2 Routine Positive Response Page page 33 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20. Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
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 & Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21. Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
The server shall check whether the individual modules are complete and compatible with one another. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The consistency check shall be carried out solely by the server. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support the routine request according to Table 23. Details & reviewer feedbackSection 8.4.1 Request Page page 35 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support the routine positive response according to Table 24. Details & reviewer feedbackSection 8.4.2 Positive Response Page page 36 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The server shall support parameter routineStatus routineResult formatted according to Table 25. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 36 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order. Details & reviewer feedbackSection 8.4.4.3 Parameter routineResultProof Page page 37 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The hash algorithm shall be SHA512. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The server shall return in the parameter routineResultProof the signed hash. Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server shall support the routine request according to Table 26. Details & reviewer feedbackSection 8.5.1 Request Page page 39 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall support the routine negative response according to CVS33. Details & reviewer feedbackSection 8.5.4 Routine 0xCAFE Parameters Page page 39 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
The server shall implement SDSC structure as defined in CVS154. Details & reviewer feedbackSection 9.1 General Requirements on SDSC 9.1.1 SDSC Structure Page page 40 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The range start field shall be the memory address offset from the dataLocator field. Details & reviewer feedbackSection 9.1.2 SDSC Sanity Check Page page 40 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The range length field shall be the number of bytes to be verified. Details & reviewer feedbackSection 9.1.2 SDSC Sanity Check Page page 40 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The vehicle manufacturer shall review and accept the proposals for every dataLocator. Details & reviewer feedbackSection 9.1.2 SDSC Sanity Check Page page 40 Feature / Interface None / OEM/Customer Review Interface Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154. Details & reviewer feedbackSection 9.1.2 SDSC Sanity Check Page page 40 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. Details & reviewer feedbackSection 9.2 Software Verification Page page 41 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. Details & reviewer feedbackSection 9.2 Software Verification Page page 41 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. Details & reviewer feedbackSection 9.2 Software Verification Page page 41 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation. Details & reviewer feedbackSection 9.2 Software Verification Page page 41 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
If NOT_OK is returned, the server shall not accept the new software for execution. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
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. Details & reviewer feedbackSection 9.3 Software decryption Page page 42 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
The cipher shall be reinitialized for each new Encryption entry. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
According to best practise received data shall be decrypted “on the fly” before storing to NVM. Details & reviewer feedbackSection 10 Non-volatile server memory programming complete flow Page page 42 Supplier proposal Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. |
If as a deviation with respect to Details & reviewer feedbackSection 4 General requirements Page page 9 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
If the performance requirements Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
or Details & reviewer feedbackSection 6.1 Requirements for servers to support programming Page page 21 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
In case of divergences between CVS124 and Table 3, this document takes precedence. Details & reviewer feedbackSection 6.1.1 Boot software description and requirements Page page 22 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Negative Response Details & reviewer feedbackSection 7.2.3 Negative Response Page page 27 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Negative Response Details & reviewer feedbackSection 7.4.3 Negative Response Page page 29 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. |
It is server specific the generator polynomial and initial value to be used. Details & reviewer feedbackSection 8.2 Routine 0x2202 – Check Memory Block Page page 30 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Table 16: Routine 0x2202 Positive Response Format Byte Description Cvt Byte Value #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkMemory [byte#1] M 0x22 #4 routineIdentifier (LSB) checkMemory [byte#2] M 0x02 #5 routineStatus routineResult M 0x00-0xFF 8.2.3 Negative Response Details & reviewer feedbackSection 8.2.3 Negative Response Page page 31 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
. Details & reviewer feedbackSection 8.3.4 Routine 0xFF00 Parameters Page page 34 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 4 | Linked diagrams: 0
|
8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 36 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 3 | Linked diagrams: 0
|
• Routine 0xFF00 Erase Memory Details & reviewer feedbackSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Negative Response Details & reviewer feedbackSection 8.5.3 Negative Response Page page 39 Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
Reads like a requirement but no customer requirement ID was identified in the source. Confirm with the customer before baselining — not counted as a confirmed requirement.
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 Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. DetailsSection 8.4.4 Routine 0xFF01 Parameters Page page 36 Security capability Diagnostic security |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 4 General requirements Page page 9 |
When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 4.2 Software architecture requirements Page page 10 |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 5 Detailed programming sequence Page page 12 |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 6.1 Requirements for servers to support programming Page page 21 |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 6.1 Requirements for servers to support programming Page page 21 |
(requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. DetailsSection 7.1.1 Request Page page 25 Feature / Interface Secure software update and flash readiness / None |
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. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 9.1.2 SDSC Sanity Check Page page 40 |
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”. Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. DetailsSection page-1 Page 1 Page page 1 |
The User shall apply the latest version of this CVS123-2. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection page-1 Page 1 Page page 1 |
For this reason, only the server is required to support the specified sequence. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 2.3 Relation to other specifications Page page 5 |
A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 4 General requirements Page page 9 |
If the microcontroller supports HW protection, this shall be used. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 4 General requirements Page page 9 |
Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 4.3 Software distribution requirements Page page 11 |
The causes specified in (ISO14229-1:2020) shall be regarded as examples. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 6.1.1 Boot software description and requirements Page page 22 |
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). Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). DetailsSection 8.4.1 Request Page page 35 |
Other methods shall be agreed upon with OEM. Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. DetailsSection 10 Non-volatile server memory programming complete flow Page page 42 |
Descriptive or contextual statements with a customer ID but no binding (shall/must) wording.
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. DetailsSection 4.2 Software architecture requirements Page page 10 |
Alternatively, it may be a client strategy to always update certain entities prior to a software update. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 Feature / Interface Secure software update and flash readiness / None |
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. DetailsSection 2.1 Summary Page page 4 Security capability Diagnostic security |
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. DetailsSection 4.3 Software distribution requirements Page page 11 Feature / Interface Secure software update and flash readiness / External Interfaces; OEM/Customer Review Interface |
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. DetailsSection 4.3 Software distribution requirements Page page 11 Feature / Interface Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface |
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. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required. DetailsSection 5.1.4 Programming Phase #2 Page page 20 Feature / Interface Secure software update and flash readiness / None |
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. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
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. DetailsSection 6.1.1 Boot software description and requirements Page page 23 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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). DetailsSection 9 Software Verification and Encryption Requirements Page page 40 Feature / Interface Security evidence and traceability / OEM/Customer Review Interface Security capability Cybersecurity requirement handling Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. DetailsSection 9.2 Software Verification Page page 41 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server may execute other checks to verify the software before concluding if the installed software shall be accepted. DetailsSection 10 Non-volatile server memory programming complete flow Page page 42 |
This document specifies the method to perform software download using Software Update Variant 2 (SUV2). DetailsSection 1 Scope Page page 4 Feature / Interface Secure software update and flash readiness / None |
The vehicle manufacturer implementation of the Authentication service (0x29) is defined in CVS31 and SecuredDataTransmission service (0x84) is defined in CVS32. DetailsSection 2 Overview 2.1 Summary Page page 4 |
While the requirements are applicable for programmable servers, some of the programming steps outlined in this specification (CommunicationControl and ControlDTCSetting) do not primarily target the programmable ECU, but the other ECUs on the same network which need to support the programming of the targeted ECU. DetailsSection 2.1 Summary Page page 4 Feature / Interface Secure software update and flash readiness / None |
Support for programming as well as support for programming of other ECUs on the same network involves supporting what is referred to as pre- and post-programming steps. DetailsSection 2.1 Summary Page page 4 Feature / Interface Secure software update and flash readiness / None |
This specification is based on ISO14229-1:2020 and as such supports a “single server” approach to non-volatile memory programming with the intention to simplify client software development without significantly complicating server software development. DetailsSection 2.1 Summary Page page 4 Feature / Interface Secure software update and flash readiness / None |
With a single server objective, an ECU will appear to be programmable through communication with a single diagnostic server even if the ECU in fact implements two or more diagnostic servers – one in the boot loader and one in each application – and in reality will be programmed through communication with either one of them or both. DetailsSection 2.1 Summary Page page 4 |
Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than DetailsSection 2.1 Summary Page page 4 Feature / Interface Secure software update and flash readiness / None |
The target readers of this specification are ECU suppliers, which can be either internal or external in relation to the vehicle manufacturer. DetailsSection 2.2 Target Reader Page page 5 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
In both cases, whenever the term “ECU supplier” or just “supplier” is used in this specification it refers to the company and organization which is responsible for the implementation and delivery of the ECU according to the requirements in this specification. DetailsSection 2.3 Relation to other specifications Page page 5 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The following documents are normative and indispensable for the application of this document: • ISO14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements • CVS124, Traton Specification on Unified diagnostic services (UDS) requirements • CVS154, DSC Specification • CVS31, Authenticate 0x29 • CVS36, Secure ECU Parametrization • CVS32, SecuredDataTranmission 0x84 • CVS33, Entity Management Protocol (EMP) • CVS34, Entity Management Protocol (EMP) Basic Entity Definition DetailsSection 2.3 Relation to other specifications Figure 1: Overview of relation between specifications Page page 5 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Boot loaders need to be updated by the vehicle manufacturer on aftermarket workshop scenarios or at a test bench during component testing, when the ECU is mounted in a vehicle during system testing or in production to fix bugs. DetailsSection 4 General requirements Page page 9 |
The “boot parameter module” permits a generic bootloader to be an ECU application platform (ECU HW + boot loader software). DetailsSection 4.2 Software architecture requirements Page page 10 |
It is within the scope of this specification that flash files delivered from the supplier can be encrypted by the vehicle manufacturer before storing in the vehicle manufacturer offboard database, but the server decryption of the received data will always restore it to servers memory into original data delivered by the supplier. DetailsSection 4.3 Software distribution requirements Page page 11 Feature / Interface Secure software update and flash readiness / None |
If a valid application is present in the ECU, some of the services described in the programming sequence will be executed in the application. DetailsSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None |
Each programming step will specify an addressing method (physical or functional), an SPRMIB (suppressPosRspMsgIndicationBit) bit value and other parameter values for the service(s) posted by the client. DetailsSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None |
The numbering of the programming sequence steps in this document generally has a well- defined relation to the numbering of the sequence steps in (ISO14229-1:2020). DetailsSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None |
Programming phase #1 is defined to program a server (e.g., download of application software, application data or boot software). DetailsSection E.g., (ISO14229-1:2020) Page page 12 Feature / Interface Secure software update and flash readiness / None |
For further information on the service details and programming messages structure regarding the SecuredDataTransmission (0x84) service, refer to CVS32. DetailsSection 5 Detailed programming sequence Page page 12 Feature / Interface Secure software update and flash readiness / None |
The sequence shown in the following figure shows the Pre-Programming step of phase #1. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 13 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
When this step is entered, the ECU is assumed to be in a state which enables it to receive UDS service requests. DetailsSection 5.1.1.1 P1Pre1: Init the data link Page page 14 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
For each server in the network, depending on whether an application has been successfully flashed before, it will run in application or boot mode. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client posts a functionally addressed DiagnosticSessionControl (0x10) service request with sessionType equal to DefaultSession and the SPRMIB not set. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
If servers which support wake-up on CAN are not awake before, this request causes them to wake-up. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
All servers available on the network and their diagnostic addresses are identified from the positive responses to this request. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
The client then posts physically or functionally addressed ReadDataByIdentifier (0x22) service requests to collect additional identification data from each identified server. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Get (0x01). DetailsSection 5.1.1.2 P1PreA: EMP (Get entities) Page page 14 |
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. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Set (0x00). DetailsSection 5.1.1.3 P1PreB: EMP (Set entities) Page page 14 |
In this step, the client will set a new SDSC entity, and it is client dependent if and what other entities are relevant to be set/update for performing the remaining steps of the sequence. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
The client post physically addressed authentication sequence based on CVS31 with SPRMIB not set. DetailsSection 5.1.1.4 P1PreC: Authentication Sequence Page page 14 |
The client posts a functionally addressed DiagnosticSessionControl (0x10) service request with sessionType equal to extended diagnostic session and the SPRMIB set. DetailsSection 5.1.1.5 P1Pre2: Diagnostic Session Control (extended Diagnostic Session) Page page 15 |
From this point, onwards (throughout the entire programming sequence) the client posts functionally addressed TesterPresent (0x3E) service requests at regular intervals, with the SPRMIB set, with the purpose to make the server(s) stay in the currently active non-default session and maintain its authenticated state. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 Feature / Interface Secure software update and flash readiness / None |
The client disables the setting of DTCs in each server by posting a functionally addressed ControlDTCSetting (0x85) service request with the sub-function parameter DTCSettingType set to off and the SPRMIB set. DetailsSection 5.1.1.6 P1Pre5: Control DTC Setting (DTC setting type = off) Page page 15 |
If the server is executing in the boot loader it will accept the request without performing any action, as DTCs are already disabled (DTC setting not supported by boot loader). DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
The client disables the transmission of non-diagnostic messages by posting a functionally addressed CommunicationControl (0x28) service request with parameter controlType set to enableRxAndDisableTx, parameter communicationType set to normalCommunicationMessages and SPRMIB set. DetailsSection 5.1.1.7 P1Pre7: Communication Control (disable non-diagnostic communication) Page page 15 |
If the server is executing in the boot loader when this service request is received no action will be performed by the server as non-diagnostic messages are already disabled. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
Link control is only applicable to standalone programming (i.e., when the ECU is not mounted in the vehicle) at vehicle manufacturer premises when no application has been programmed by the supplier, communication network permits baud rate switch (e.g CAN) and only if performance requirement cannot be met without using this service. DetailsSection 5.1.1.8 P1Pre9: Link Control (verify and/or switch baud rate) Page page 15 Feature / Interface Secure software update and flash readiness / None |
The client posts a physically addressed LinkControl (0x87) service request with parameter linkControlType set to verifyBaudrateTransitionWithFixedParameter, SPRMIB not set and linkControlModeIdentifier set to desired baud rate. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
After reception of a positive response message the client posts a physically addressed LinkControl (0x87) service request with sub-function parameter linkControlType set to transitionMode and the SPRMIB set. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
The client will then switch to the new baud rate and re-establish communication with the ECU considering the maximum specified time it will take for the server to start responding to the newly selected baud rate. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
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. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 15 |
The sequence in Figure 3 shows the programming step of phase #1. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The information to verify integrity of the software is contained in software data security container (SDSC), which is transmitted in P1PreB step. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
If SDSC dictates decryption, the decryption keys are contained in software data security container (SDSC) which is transmitted in P1PreB step. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 16 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The client posts a physically addressed DiagnosticSessionControl (0x10) service request with sub-function parameter diagnosticSessionType set to ProgrammingSession and the SPRMIB not set. DetailsSection 5.1.2.1 P1Pro1: Diagnostic Session Control (Programming Session) Page page 17 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
If CommunicationControl has not been previously called in the Extended Diagnostic Session the server rejects the request with negative response code NRC 0x22 (conditionsNotCorrect). DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
Implementation hint: If the server is executing the application the server sets a “programming request” flag (C2, see section Boot software session requirements). DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Feature / Interface Secure software update and flash readiness / None |
The boot manager notes the programming request and starts the boot loader. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Feature / Interface Secure software update and flash readiness / None |
Implementation hint: The boot manager recognizes the programming request by checking the “programming request” flag (C2). DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Feature / Interface Secure software update and flash readiness / None |
Implementation hint: The boot manager or the boot loader resets the “programming request” flag (C2). DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 Feature / Interface Secure software update and flash readiness / None |
Finally, the boot loader sends a positive response. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 |
The client post physically addressed authentication sequence based on Authenticate 0x29 with SPRMIB not set. DetailsSection 5.1.2.2 P1ProB: Authentication Page page 17 |
The client posts a physically addressed RoutineControl (0x31) (eraseMemory) service request with a memory start address and a memory size value set for parameter RoutineControlOptionRecord and the SPRMIB not set. DetailsSection 5.1.2.3 P1Pro6: Routine Control (erase Memory) Page page 17 |
Implementation hint: The server resets the “application valid” flag (C1, see CVS124 DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 |
The client posts physically addressed RequestDownload (0x34) service requests with the SPRMIB not set. DetailsSection 5.1.2.4 P1Pro9.1: Request Download Page page 17 |
If the boot software module is updated in this step, DID 0xF180 (bootSoftwareIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the boot software module. DetailsSection 5.1.2.5 P1Pro9.2: Sequences of Transfer Data and Request Transfer Exit Page page 18 |
If the application software module is updated in this step, DID 0xF181 (applicationSoftwareIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application software module. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
If the application data module is updated in this step DID 0xF182 (applicationDataIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application data module. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
If the application software module is updated in this step, DID 0xF187 (vehicleManufacturerSparePartNumberDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application data module. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
If the application software module is updated in this step, DID 0xF188 (vehicleManufacturerECUSoftwareNumberDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application software module. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
It is client specific if P1Pro10 will be sent as part of programming phase #1. DetailsSection 5.1.2.6 P1Pro10: Routine Control (Check Memory Block) Page page 18 Feature / Interface Secure software update and flash readiness / None |
This routineIdentifier is supported to allow process improvement during the software update since it allows client to react as soon as a corruption is identified in the transferred module data. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 Feature / Interface Secure software update and flash readiness / None |
The client posts a physically addressed RoutineControl (0x31) (checkMemory) service request with the SPRMIB not set. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
As part of the routine checks, the server will use the information defined in SDSC to perform the software verification, see 9.2. DetailsSection 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page page 19 Feature / Interface Security evidence and traceability / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
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. DetailsSection 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page page 19 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The sequence shown in the following figure shows the post-programming step of phase #1. DetailsSection 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page page 19 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
After the consistency check (independent of the result), the client initiates a server restart by posting a physically addressed ECUReset (0x11) (hardReset) service request with the SPRMIB not set. DetailsSection Figure 4: Programming phase #1 – Post-Programming step 5.1.3.1 P1Pos1: ECU Reset (hard reset) Page page 19 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The server responds positively to the request before the reset takes place. DetailsSection 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page page 19 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
After reset, if the ECU hardware/software is deemed to be consistent and all software and data identification DIDs in CVS124 which have been flashed or written as part of the programming DetailsSection 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network Page page 19 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The application reads and applies the boot parameter values from the boot parameter module. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
Implementation hint: The boot manager checks the “application valid” flag (C1) to see if the ECU hardware/software is consistent and all software and data identification DIDs in CVS124 contain non-default values. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
Implementation hint: If the “application valid” flag (C1) indicates that the ECU application state is not valid, the boot manager will execute the boot loader. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
If the boot loader is executed and a boot parameter module exists, the boot loader reads and applies the boot parameter values from this module. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Set (0x00). DetailsSection 5.1.3.3 P1PosB: EMP (Set entities) Page page 20 |
The programming phase #2 (server configuration or also known as parametrization) as defined in ISO 14229-2 is defined in CVS36. DetailsSection 5.1.4 Programming Phase #2 Page page 20 Feature / Interface Secure software update and flash readiness / None |
This is to keep the programming time to a minimum. DetailsSection 6.1 Requirements for servers to support programming Page page 21 Feature / Interface Secure software update and flash readiness / None |
This is to shorten the time for the data transfer from the tester to the ECU to be programmed. DetailsSection 6.1 Requirements for servers to support programming Page page 21 |
In case of e.g., flash interruption resetting the DIDs to default values will enable the client to identify the ECU as not having a valid application. DetailsSection 6.1 Requirements for servers to support programming Page page 21 Feature / Interface Secure software update and flash readiness / None |
This means, for example, that loss of application server specific diagnostic address, -bitrate or - system name as a result of a failure during boot parameter module programming in the workshop is not acceptable. DetailsSection 6.1.1 Boot software description and requirements Page page 22 Feature / Interface Secure software update and flash readiness / None |
For a server, it is the combination of services support in CVS124 and Table 3 that will constitute the complete picture of supported services. DetailsSection 6.1.1 Boot software description and requirements Page page 22 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. DetailsSection 7.1 RequestDownload (0x34) Service Page page 24 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The software to be received over TransferData (0x36) is to be considered NOT_OK until a verification takes place. DetailsSection 7.1.1 Request Page page 25 Feature / Interface Security evidence and traceability / None Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Considering that hashing, compression and encryption methods were used prior to transfer a software to the server, the server will decrypt, decompress, and perform software hashing comparison verification in this respective order. DetailsSection 7.1.4 Service 0x34 Parameters Page page 26 Feature / Interface Security evidence and traceability / None Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
Table 14: Routine support for Safe State Conditions RID Name Safe State 0x2202 Check Memory Block M 0xFF00 EraseMemory M - 0xFF01 CheckProgrammingDependencies M M 0xCAFE Entity Management Protocol (EMP) M M M = Mandatory 8.2 Routine 0x2202 – Check Memory Block The RoutineIdentifier allows the client to start a server routine which verifies the correctness of a programmed module. DetailsSection 8.2 Routine 0x2202 – Check Memory Block Page page 30 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 2 | Linked diagrams: 0
|
SUV2_REQ 4 prevents the scenario of erasing the copied bootloader while boot loader update and leaving the ECU without any bootloader. DetailsSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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. DetailsSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
This RoutineIdentifier value allows the client to start a consistency check of the server. DetailsSection 8.4 Routine 0xFF01 – CheckProgrammingDependencies Page page 35 Feature / Interface Secure software update and flash readiness / None Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Details over the integrity check can be found on chapter 9.2. DetailsSection 8.4.1 Request Page page 35 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The receipt number is received as part of the EMP message whenever a SDSC is set, please refer to CVS34. DetailsSection 8.4.4 Routine 0xFF01 Parameters Page page 37 |
For information on receipt-keys, please refer to CVS34. DetailsSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The SDSC content, including the reference hash used for software verification, is signed as part of the set request when transmitted over EMP. DetailsSection 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) Page page 38 Feature / Interface Security evidence and traceability / None Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
SDSC supports verification entries, encryption entries and items as defined in DSC. DetailsSection 9.1.2 SDSC Sanity Check Page page 40 Feature / Interface Security evidence and traceability / None |
The dataLocator field is used to provide to the server the means to identify which module the verification or encryption entries refer to. DetailsSection 9.1.2 SDSC Sanity Check Page page 40 Feature / Interface Security evidence and traceability / None |
The Non-volatile server memory programming complete flow can be found in Annex B. DetailsSection 10 Non-volatile server memory programming complete flow Page page 42 Feature / Interface Secure software update and flash readiness / None |
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. DetailsSection 2.1 Summary Page page 4 |
If the application was started, it checks if application initialization is required. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
This specification targets ECUs, not clients. DetailsSection 2.1 Summary Page page 4 |
Several terms that are used in this document but not defined in Table 1 are defined by ISO or in the document CVS124. DetailsSection 3 Terms, definitions and abbrevations 3.1 Definitions of terms Page page 6 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
Requirements are prefixed “SUV2_REQ”. DetailsSection 3.3 Naming conventions Page page 8 |
Similarly, informative text is prefixed “SUV2_INFO”. DetailsSection 3.3 Naming conventions Page page 8 |
For definition of DID 0xF197 see CVS124. DetailsSection 4.3 Software distribution requirements Page page 11 |
In this step, it is client dependent if and what cyber security entities are relevant to be read for performing the remaining steps of the sequence. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
For reference on EMP control routine, see CVS33. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
For reference on EMP control routine, see CVS33. DetailsSection 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming Page page 14 |
If the server is executing the application the server responds to the request with one or more negative response codes NRC 0x78 (requestCorrectlyReceived-ResponsePending) and triggers a server restart. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 |
The server erases the applicable SW identification DIDs, see Erase Memory routine requirements in 8.3. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 17 |
According to DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
The response of this routineIdentifier allows the client to identify if the specific transferred block is corrupted. DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
According to DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
According to DetailsSection 5.1.2 Programming step of phase #1 – Download of application software and data Page page 18 |
According to DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
In this step, it is client dependent if and what entities are relevant to be set after updating the software. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
For reference on EMP control routine, see CVS33. DetailsSection 5.1.4 Programming Phase #2 Page page 20 |
For more information on SDSC, see chapter 9. DetailsSection 7.1.1 Request Page page 25 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
If an encryptionEntry match is found, see chapter 9.3. DetailsSection 7.1.1 Request Page page 25 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
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 DetailsSection 8.2.3 Negative Response Page page 31 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
This RoutineIdentifier value allows the client to start a routine which erases ECU internal non- volatile memory. DetailsSection 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) Page page 32 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check. DetailsSection 8.4.1 Request Page page 35 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
This parameter consist of the length of the routineResultProof parameter. DetailsSection 8.4.4 Routine 0xFF01 Parameters Page page 37 Related Tables / DiagramsLinked tables: 1 | Linked diagrams: 0
|
For the context of SDSC, range is defined as: • Start = memory address offset to be verified/decrypted. DetailsSection 9.1.2 SDSC Sanity Check Page page 40 |
For the context of SDSC, dataLocator is defined as an identification the server uses to locate the software module. DetailsSection 9.1.2 SDSC Sanity Check Page page 40 |
In DSC sanity check, there is a specific area of application sanity check which depends on the context of the general DSC. DetailsSection 9.2 Software Verification Page page 41 |
The referenceHash defines the reference hash value to be used in the hash comparison. DetailsSection 9.2 Software Verification Page page 41 |
Erased-only bytes are parts of the memory module that are not programmed with data. DetailsSection 9.2 Software Verification Page page 41 Related Tables / DiagramsLinked tables: 0 | Linked diagrams: 1
|
The received data to decrypt may only be parts of a software module and it will be based on the range defined. DetailsSection 10 Non-volatile server memory programming complete flow Page page 42 |
EncryptionEntries are not present if software is not encrypted. DetailsSection 10 Non-volatile server memory programming complete flow Page page 42 |
Definitions, abbreviations, document history, scope and other boilerplate. Not customer requirements.
Definitions of terms 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. shall be implemented in the boot software code. 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. It must be clearly separated from the application software. For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. Application software module Contains all vehicle functions required for the normal server operation. The value of this variable may be used by the application to determine whether or not initialization is required. 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. 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. DetailsSection 3.1 Definitions of terms Page page 6 Feature / Interface Secure software update and flash readiness / None Security capability Diagnostic security |
Abbreviated terms 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. Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memory DetailsSection 3.2 Abbreviated terms Page page 7 Feature / Interface Secure software update and flash readiness / OEM/Customer Review Interface |
Normative references 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). 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. #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. #008AFFFF # #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB Figure 8 – Memory layout DetailsSection 11 Normative references Page page 48 Feature / Interface Secure software update and flash readiness / None |
Page 1 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. DetailsSection page-1 Page 1 Page page 1 Feature / Interface Secure software update and flash readiness / None |
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 | Secure software update and flash readiness — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0037; RFQX-CVS123-2-0072. | Secure software update and flash readiness | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-BOOT-002 | Secure software update and flash readiness — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure (Hardware domain; allocated to Hardware Platform).From this PDF: RFQX-CVS123-2-0039; RFQX-CVS123-2-0258. | Secure software update and flash readiness | None | None | Supplier-Owned | Candidate | Review + Test + table/diagram context review |
| SSR-BOOT-003 | Bootloader and Application State Handling — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (System domain; allocated to System Core).From this PDF: RFQX-CVS123-2-0044. | Bootloader and Application State Handling | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-BOOT-004 | Bootloader and Application State Handling — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (IT / backend domain; allocated to Backend and IT Systems).From this PDF: RFQX-CVS123-2-0055. | Bootloader and Application State Handling | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-BOOT-005 | Bootloader and Application State Handling — Bootloader and Application State HandlingThe ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (Software domain; allocated to Application Software).From this PDF: RFQX-CVS123-2-0179. | Bootloader and Application State Handling | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-COM-002 | Secure Communication and Boundary Control — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (System domain; allocated to System Core).From this PDF: RFQX-CVS123-2-0173. | Secure Communication and Boundary Control | None | None | Supplier-Owned | Candidate | Review + Test + table/diagram context review |
| SSR-COM-006 | Secure Communication and Boundary Control — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (Software domain; allocated to Application Software).From this PDF: RFQX-CVS123-2-0211. | Secure Communication and Boundary Control | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-COM-009 | 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 (IT / backend domain; allocated to Backend and IT Systems).From this PDF: RFQX-CVS123-2-0241. | Secure communication and freshness protection | None | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-CON-002 | Cybersecurity Concept and Evidence — Cybersecurity Concept and EvidenceThe supplier shall produce and maintain the cybersecurity concept and verification evidence covering Cybersecurity Concept and Evidence (Cybersecurity domain; allocated to Security Services; security capability: Cybersecurity requirement handling; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0196; RFQX-CVS123-2-0201; RFQX-CVS123-2-0243. | Cybersecurity Concept and Evidence | Cybersecurity requirement handling | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-DAI-003 | Data Authenticity and Integrity Verification — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data (IT / backend domain; allocated to Backend and IT Systems).From this PDF: RFQX-CVS123-2-0240; RFQX-CVS123-2-0279; RFQX-CVS123-2-0297. | Data Authenticity and Integrity Verification | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-DAI-004 | Data Authenticity and Integrity Verification — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data (Software domain; allocated to Application Software).From this PDF: RFQX-CVS123-2-0061; RFQX-CVS123-2-0110; RFQX-CVS123-2-0246; RFQX-CVS123-2-0277; RFQX-CVS123-2-0278; RFQX-CVS123-2-0337. | Data Authenticity and Integrity Verification | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-DAI-005 | Security evidence and traceability — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Security evidence and traceability data and reject manipulated or unauthenticated data (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0285. | Security evidence and traceability | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-DIAG-002 | Diagnostic Services — Diagnostic ServicesThe ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0046; RFQX-CVS123-2-0251. | Diagnostic Services | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Test + table/diagram context review |
| SSR-HW-001 | Hardware / HSM / Secure Storage — Hardware / HSM / Secure StorageThe ECU hardware shall provide the platform and secure-storage capabilities required for Hardware / HSM / Secure Storage (Hardware domain; allocated to Hardware Platform; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0316; RFQX-CVS123-2-0334. | Hardware / HSM / Secure Storage | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-RBAC-001 | Secure Diagnostics / RBAC — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model (Cybersecurity domain; allocated to Security Services; security capability: Diagnostic security; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0034; RFQX-CVS123-2-0047; RFQX-CVS123-2-0052; RFQX-CVS123-2-0056; RFQX-CVS123-2-0166; RFQX-CVS123-2-0192; RFQX-CVS123-2-0242; RFQX-CVS123-2-0303. | Secure Diagnostics / RBAC | Diagnostic security | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-RBAC-002 | Secure software update and flash readiness — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Secure software update and flash readiness, restricting security-relevant diagnostic services per the OEM-agreed role model (Cybersecurity domain; allocated to Security Services; security capability: Authentication).From this PDF: RFQX-CVS123-2-0078; RFQX-CVS123-2-0079; RFQX-CVS123-2-0244. | Secure software update and flash readiness | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-SDT-001 | Secure Data Transfer / Data Security Container — Secure Data Transfer / Data Security ContainerThe ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme (Software domain; allocated to Application Software).From this PDF: RFQX-CVS123-2-0114; RFQX-CVS123-2-0204; RFQX-CVS123-2-0247; RFQX-CVS123-2-0261. | Secure Data Transfer / Data Security Container | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-SDT-002 | Secure Data Transfer / Data Security Container — Secure Data Transfer / Data Security ContainerThe ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme (Hardware domain; allocated to Hardware Platform).From this PDF: RFQX-CVS123-2-0350. | Secure Data Transfer / Data Security Container | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-SYS-001 | System Function — System FunctionThe ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (System domain; allocated to System Core; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0036; RFQX-CVS123-2-0051; RFQX-CVS123-2-0175; RFQX-CVS123-2-0176; RFQX-CVS123-2-0193; RFQX-CVS123-2-0268; RFQX-CVS123-2-0275; RFQX-CVS123-2-0294; RFQX-CVS123-2-0317; RFQX-CVS123-2-0340; RFQX-CVS123-2-0341; RFQX-CVS123-2-0342. | System Function | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test + table/diagram context review |
| SSR-SYS-002 | System Function — System FunctionThe ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (Process / compliance domain; allocated to Compliance Process; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0320. | System Function | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test + table/diagram context review |
| SSR-SYS-003 | System Function — System FunctionThe ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0058; RFQX-CVS123-2-0059; RFQX-CVS123-2-0066; RFQX-CVS123-2-0068; RFQX-CVS123-2-0168; RFQX-CVS123-2-0177; RFQX-CVS123-2-0181; RFQX-CVS123-2-0266; RFQX-CVS123-2-0319; RFQX-CVS123-2-0331. | System Function | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test + table/diagram context review |
| SSR-TOOL-002 | Tooling / IT / Evidence Storage — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0112; RFQX-CVS123-2-0169; RFQX-CVS123-2-0186; RFQX-CVS123-2-0200; RFQX-CVS123-2-0209; RFQX-CVS123-2-0220; RFQX-CVS123-2-0222; RFQX-CVS123-2-0225; RFQX-CVS123-2-0226; RFQX-CVS123-2-0228; RFQX-CVS123-2-0232; RFQX-CVS123-2-0233; RFQX-CVS123-2-0235; RFQX-CVS123-2-0237; RFQX-CVS123-2-0238; RFQX-CVS123-2-0250; RFQX-CVS123-2-0254; RFQX-CVS123-2-0262; RFQX-CVS123-2-0263; RFQX-CVS123-2-0265; RFQX-CVS123-2-0273; RFQX-CVS123-2-0276; RFQX-CVS123-2-0281; RFQX-CVS123-2-0282; RFQX-CVS123-2-0284; RFQX-CVS123-2-0292; RFQX-CVS123-2-0295; RFQX-CVS123-2-0298; RFQX-CVS123-2-0302; RFQX-CVS123-2-0308; RFQX-CVS123-2-0309; RFQX-CVS123-2-0310; RFQX-CVS123-2-0311; RFQX-CVS123-2-0313; RFQX-CVS123-2-0323; RFQX-CVS123-2-0325; RFQX-CVS123-2-0329. | Tooling / IT / Evidence Storage | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-TOOL-003 | Tooling / IT / Evidence Storage — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage (Software domain; allocated to Application Software).From this PDF: RFQX-CVS123-2-0167; RFQX-CVS123-2-0190; RFQX-CVS123-2-0203; RFQX-CVS123-2-0205; RFQX-CVS123-2-0213; RFQX-CVS123-2-0214; RFQX-CVS123-2-0215; RFQX-CVS123-2-0218; RFQX-CVS123-2-0223; RFQX-CVS123-2-0224; RFQX-CVS123-2-0227; RFQX-CVS123-2-0229; RFQX-CVS123-2-0230; RFQX-CVS123-2-0234; RFQX-CVS123-2-0239; RFQX-CVS123-2-0256; RFQX-CVS123-2-0260; RFQX-CVS123-2-0269; RFQX-CVS123-2-0328; RFQX-CVS123-2-0336; RFQX-CVS123-2-0339. | Tooling / IT / Evidence Storage | None | None | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-UPD-001 | Secure software update and flash readiness — Software Update / FlashingThe ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0042; RFQX-CVS123-2-0048; RFQX-CVS123-2-0049; RFQX-CVS123-2-0050; RFQX-CVS123-2-0178; RFQX-CVS123-2-0184; RFQX-CVS123-2-0188; RFQX-CVS123-2-0197; RFQX-CVS123-2-0199; RFQX-CVS123-2-0299; RFQX-CVS123-2-0333. | Secure software update and flash readiness | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-UPD-002 | Secure software update and flash readiness — Software Update / FlashingThe ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (System domain; allocated to System Core; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0043; RFQX-CVS123-2-0062; RFQX-CVS123-2-0064; RFQX-CVS123-2-0070; RFQX-CVS123-2-0071; RFQX-CVS123-2-0185; RFQX-CVS123-2-0271. | Secure software update and flash readiness | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-UPD-003 | Secure software update and flash readiness — Software Update / FlashingThe ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0164; RFQX-CVS123-2-0187. | Secure software update and flash readiness | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test + table/diagram context review |
| SSR-UPD-004 | Secure software update and flash readiness — Software Update / FlashingThe ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (Hardware domain; allocated to Hardware Platform; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0165. | Secure software update and flash readiness | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test + table/diagram context review |
| SSR-VV-002 | Security evidence and traceability — Verification and ValidationThe supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0207; RFQX-CVS123-2-0335. | Security evidence and traceability | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| SSR-VV-003 | Security evidence and traceability — Verification and ValidationThe supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface).From this PDF: RFQX-CVS123-2-0216; RFQX-CVS123-2-0217; RFQX-CVS123-2-0326. | Security evidence and traceability | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test + table/diagram context review |
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Secure communication and freshness protection; Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability |
| Impacted interfaces | External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface |
| Impacted security capabilities | Authentication; Cybersecurity requirement handling; Diagnostic security |
| 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 (sample: 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; High/Low/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 (sample: 12 of 15) |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Confirm with customer whether this is a binding requirement and assign a customer ID. |
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/High/Low; High/High/Medium; High/Low/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 (sample: 12 of 15) |
Generated from document-specific requirement, traceability, SSR, and open-point evidence.
flowchart LR
doc["CVS123-2.pdf"]
d0["Authentication"]
doc --> d0
d1["Cybersecurity requirement handling"]
doc --> d1
d2["Diagnostic security"]
doc --> d2
f0["Feature: Secure communication and freshness protection"]
doc --> f0
f1["Feature: Secure software update and flash readiness"]
doc --> f1
f2["Feature: 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-001"]
doc --> o0
o1["Open point: OP-002"]
doc --> o1
o2["Open point: OP-004"]
doc --> o2
CVS123-2.pdf
Software Update Standard
Hardware / Platform
178 requirements, 138 information, 29 SSRs
27 tables, 13 diagrams
Markdown-derived requirements and registers; OCR disabled; no downstream PDF analysis
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| RFQX-CVS123-2-0001 | None | Covered by Existing Supplier System Requirement | n/a | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0002 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0003 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0004 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0005 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0006 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0007 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0008 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0009 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0010 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0011 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0012 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0013 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0014 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0015 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0016 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0017 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0018 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0019 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0020 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0021 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0022 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0023 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0024 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0025 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0026 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0027 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0028 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0029 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0030 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0031 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0032 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0033 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0034 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0035 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0036 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0037 | SSR-BOOT-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0038 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0039 | SSR-BOOT-002 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0040 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0041 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0042 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0043 | SSR-UPD-002 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0044 | SSR-BOOT-003 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0045 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0046 | SSR-DIAG-002 | Shared Responsibility / CIA Needed | High | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0047 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0048 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0049 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0050 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0051 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0052 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0053 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0054 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0055 | SSR-BOOT-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0056 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0057 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0058 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0059 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0060 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0061 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0062 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0063 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0064 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0065 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0066 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0067 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0068 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0069 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0070 | SSR-UPD-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0071 | SSR-UPD-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0072 | SSR-BOOT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0073 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0074 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0075 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0076 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0077 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0078 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0079 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0080 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0081 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0082 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0083 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0084 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0085 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0086 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0087 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0088 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0089 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0090 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0091 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0092 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0093 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0094 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0095 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0096 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0097 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0098 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0099 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0100 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0101 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0102 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0103 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0104 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0105 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0106 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0107 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0108 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0109 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0110 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0111 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0112 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0113 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0114 | SSR-SDT-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0115 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0116 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0117 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0118 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0119 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0120 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0121 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0122 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0123 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0124 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0125 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0126 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0127 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0128 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0129 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0130 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0131 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0132 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0133 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0134 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0135 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0136 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0137 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0138 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0139 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0140 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0141 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0142 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0143 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0144 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0145 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0146 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0147 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0148 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0149 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0150 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0151 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0152 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0153 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0154 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0155 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0156 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0157 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0158 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0159 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0160 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0161 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0162 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0163 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0164 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0165 | SSR-UPD-004 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0166 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0167 | SSR-TOOL-003 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0168 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0169 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0170 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0171 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0172 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0173 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0174 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0175 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0176 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0177 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0178 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0179 | SSR-BOOT-005 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0180 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0181 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0182 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0183 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0184 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0185 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0186 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0187 | SSR-UPD-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0188 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0189 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0190 | SSR-TOOL-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0191 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0192 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0193 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0194 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0195 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0196 | SSR-CON-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0197 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0198 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0199 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0200 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0201 | SSR-CON-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0202 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0203 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0204 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0205 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0206 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0207 | SSR-VV-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0208 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0209 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0210 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0211 | SSR-COM-006 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0212 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0213 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0214 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0215 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0216 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0217 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0218 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0219 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0220 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0221 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0222 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0223 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0224 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0225 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0226 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0227 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0228 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0229 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0230 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0231 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0232 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0233 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0234 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0235 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0236 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0237 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0238 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0239 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0240 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0241 | SSR-COM-009 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| RFQX-CVS123-2-0242 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0243 | SSR-CON-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0244 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0245 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0246 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0247 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0248 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0249 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0250 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0251 | SSR-DIAG-002 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0252 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0253 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0254 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0255 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0256 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0257 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0258 | SSR-BOOT-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0259 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0260 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0261 | SSR-SDT-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0262 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0263 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0264 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0265 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0266 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0267 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0268 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0269 | SSR-TOOL-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0270 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0271 | SSR-UPD-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0272 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0273 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0274 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0275 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0276 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0277 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0278 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0279 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0280 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0281 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0282 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0283 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0284 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0285 | SSR-DAI-005 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0286 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0287 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0288 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0289 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0290 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0291 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0292 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0293 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0294 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0295 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0296 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0297 | SSR-DAI-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0298 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0299 | SSR-UPD-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0300 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0301 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0302 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0303 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0304 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0305 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0306 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0307 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0308 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0309 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0310 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0311 | SSR-TOOL-002 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0312 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0313 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0314 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0315 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0316 | SSR-HW-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0317 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0318 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0319 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0320 | SSR-SYS-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0321 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0322 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0323 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0324 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0325 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0326 | SSR-VV-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0327 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0328 | SSR-TOOL-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0329 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0330 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0331 | SSR-SYS-003 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0332 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0333 | SSR-UPD-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0334 | SSR-HW-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0335 | SSR-VV-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0336 | SSR-TOOL-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0337 | SSR-DAI-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0338 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0339 | SSR-TOOL-003 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0340 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0341 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0342 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| RFQX-CVS123-2-0343 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0344 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0345 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0346 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0347 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0348 | None | Informational Only | n/a | Non-binding; not derived. |
| RFQX-CVS123-2-0349 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| RFQX-CVS123-2-0350 | SSR-SDT-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| RFQX-CVS123-2-0351 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
CVS123-2.pdfconverted/markdown/source documentScope: this software update standard specifies system architecture design, covering 2 Overview; 2.1 Summary; 2.3 Relation to other specifications; 3 Terms, definitions and abbrevations; 3.1 Definitions of terms; 3.3 Naming conventions. System boundary and interfaces: the document constrains 2 interface(s) - OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; principal functions in scope are Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection.
Engineering obligations: 178 confirmed customer requirement(s) carry an explicit ID and normative wording and must be implemented and verified; 18 further requirement-like statement(s) have no customer ID and must be clarified before they can be baselined; 138 informational and 17 reference item(s) were separated out as non-binding. Design and security impact: affects Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection; security capabilities touched: Diagnostic security; Authentication; Cybersecurity requirement handling; 29 supplier system requirement(s) were derived from this document.
Open for the customer: 6 document-linked open point(s) - mainly Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).; 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. (sample: 3 of 6) - plus 18 unidentified requirement-like statement(s). Do not baseline these until the customer confirms. Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used.
| Field | Interpretation |
|---|---|
| Document Purpose | Scope: this software update standard specifies system architecture design, covering 2 Overview; 2.1 Summary; 2.3 Relation to other specifications; 3 Terms, definitions and abbrevations; 3.1 Definitions of terms; 3.3 Naming conventions. |
| Engineering Interpretation | System boundary and interfaces: the document constrains 2 interface(s) - OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; principal functions in scope are Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection. |
| Supplier Proposal Impact | Engineering obligations: 178 confirmed customer requirement(s) carry an explicit ID and normative wording and must be implemented and verified; 18 further requirement-like statement(s) have no customer ID and must be clarified before they can be baselined; 138 informational and 17 reference item(s) were separated out as non-binding. |
| System / Security Impact | Design and security impact: affects Secure software update and flash readiness; Secure software update and flash readiness; Security evidence and traceability; Security evidence and traceability; Secure communication and freshness protection; security capabilities touched: Diagnostic security; Authentication; Cybersecurity requirement handling; 29 supplier system requirement(s) were derived from this document. |
| Customer Clarification Impact | Open for the customer: 6 document-linked open point(s) - mainly Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).; 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. (sample: 3 of 6) - plus 18 unidentified requirement-like statement(s). Do not baseline these until the customer confirms. |
| Confidence and Limits | Confidence and limits: High confidence. Categorisation is derived from the converted Markdown (customer IDs, normative wording, and section context); no OCR or downstream PDF analysis is used. |
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| System architecture design | Groups related document requirements into a single engineering theme. | 252 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0003; RFQX-CVS123-2-0004 |
| Requirement | Groups related document requirements into a single engineering theme. | 178 | RFQX-CVS123-2-0026; RFQX-CVS123-2-0028; RFQX-CVS123-2-0034 |
| Software | Groups related document requirements into a single engineering theme. | 145 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0004; RFQX-CVS123-2-0005 |
| Information | Groups related document requirements into a single engineering theme. | 138 | RFQX-CVS123-2-0004; RFQX-CVS123-2-0005; RFQX-CVS123-2-0006 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 127 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0002; RFQX-CVS123-2-0005 |
| Secure software update and bootloader | Defines ECU-side programming, boot/application state handling, integrity checks, and update evidence. | 114 | RFQX-CVS123-2-0001; RFQX-CVS123-2-0004; RFQX-CVS123-2-0006 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 112 | RFQX-CVS123-2-0002; RFQX-CVS123-2-0007; RFQX-CVS123-2-0009 |
| Diagnostics and service access | Defines UDS service behavior, authorization expectations, safe-state checks, and diagnostic evidence. | 96 | RFQX-CVS123-2-0006; RFQX-CVS123-2-0009; RFQX-CVS123-2-0010 |
| Section | Requirements | Information | Unknown | Excluded | Total Items | Critical | Open Points | SSR Links |
|---|---|---|---|---|---|---|---|---|
| 2 Overview | 0 | 13 | 0 | 0 | 14 | 1 | 1 | 0 |
| -- 2.1 Summary | 0 | 10 | 0 | 0 | 10 | 0 | 0 | 0 |
| -- 2.3 Relation to other specifications | 0 | 3 | 0 | 0 | 4 | 1 | 1 | 0 |
| 3 Terms, definitions and abbrevations | 2 | 3 | 0 | 0 | 16 | 8 | 4 | 0 |
| -- 3.1 Definitions of terms | 2 | 1 | 0 | 0 | 12 | 7 | 3 | 0 |
| -- 3.2 Abbreviated terms | 0 | 0 | 0 | 0 | 2 | 1 | 1 | 0 |
| -- 3.3 Naming conventions | 0 | 2 | 0 | 0 | 2 | 0 | 0 | 0 |
| 4 General requirements | 24 | 7 | 0 | 0 | 36 | 12 | 4 | 11 |
| -- 4.2 Software architecture requirements | 6 | 2 | 0 | 0 | 9 | 3 | 2 | 4 |
| -- 4.3 Software distribution requirements | 8 | 4 | 0 | 0 | 13 | 2 | 2 | 3 |
| 5 Detailed programming sequence | 13 | 79 | 0 | 0 | 94 | 9 | 3 | 6 |
| -- 5.1 Programming phase #1 – Download of application software and/or application data | 8 | 74 | 0 | 0 | 83 | 4 | 1 | 3 |
| -- -- 5.1.1 Pre-programming step of phase #1 – Setup vehicle network for programming | 0 | 28 | 0 | 0 | 28 | 0 | 0 | 0 |
| -- -- 5.1.2 Programming step of phase #1 – Download of application software and data | 7 | 28 | 0 | 0 | 35 | 3 | 0 | 3 |
| -- -- 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network | 0 | 6 | 0 | 0 | 6 | 0 | 0 | 0 |
| -- -- 5.1.4 Programming Phase #2 | 1 | 12 | 0 | 0 | 14 | 1 | 1 | 0 |
| 6 Server reprogramming requirements | 28 | 6 | 0 | 0 | 37 | 10 | 3 | 12 |
| -- 6.1 Requirements for servers to support programming | 28 | 6 | 0 | 0 | 37 | 10 | 3 | 12 |
| -- -- 6.1.1 Boot software description and requirements | 13 | 3 | 0 | 0 | 17 | 5 | 3 | 8 |
| 7 Diagnostic service requirements | 29 | 5 | 0 | 0 | 35 | 18 | 1 | 7 |
| -- 7.1 RequestDownload (0x34) Service | 14 | 5 | 0 | 0 | 20 | 12 | 1 | 7 |
| -- -- 7.1.1 Request | 4 | 3 | 0 | 0 | 8 | 4 | 1 | 4 |
| -- -- 7.1.4 Service 0x34 Parameters | 6 | 1 | 0 | 0 | 7 | 5 | 0 | 3 |
| -- 7.2 TransferData (0x36) Service | 7 | 0 | 0 | 0 | 7 | 3 | 0 | 2 |
| -- -- 7.2.4 Service 0x36 Parameters | 7 | 0 | 0 | 0 | 7 | 3 | 0 | 2 |
| -- 7.4 SecuredDataTranmission (0x84) Service | 8 | 0 | 0 | 0 | 8 | 3 | 0 | 2 |
| -- -- 7.4.1 Request | 8 | 0 | 0 | 0 | 8 | 3 | 0 | 2 |
| 8 Diagnostic Routine Identifier Requirements | 62 | 12 | 0 | 0 | 76 | 21 | 2 | 16 |
| -- 8.1 Routine Session and routineControlSupport | 7 | 0 | 0 | 0 | 7 | 3 | 1 | 5 |
| -- -- 8.1.1 Routine Session Support | 7 | 0 | 0 | 0 | 7 | 3 | 1 | 5 |
| -- 8.2 Routine 0x2202 – Check Memory Block | 8 | 2 | 0 | 0 | 10 | 3 | 1 | 6 |
| -- -- 8.2.3 Negative Response | 3 | 1 | 0 | 0 | 4 | 0 | 0 | 2 |
| -- 8.3 Routine 0xFF00 – EraseMemory (erasing the program memory) | 14 | 3 | 0 | 0 | 17 | 3 | 0 | 6 |
| -- -- 8.3.2 Routine Positive Response | 2 | 0 | 0 | 0 | 2 | 0 | 0 | 1 |
| -- -- 8.3.4 Routine 0xFF00 Parameters | 6 | 0 | 0 | 0 | 6 | 1 | 0 | 4 |
| -- 8.4 Routine 0xFF01 – CheckProgrammingDependencies | 21 | 6 | 0 | 0 | 29 | 8 | 2 | 6 |
| -- -- 8.4.1 Request | 8 | 3 | 0 | 0 | 12 | 4 | 1 | 5 |
| -- -- 8.4.4 Routine 0xFF01 Parameters | 13 | 3 | 0 | 0 | 17 | 4 | 1 | 4 |
| -- 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) | 12 | 1 | 0 | 0 | 13 | 4 | 1 | 3 |
| -- -- 8.5.4 Routine 0xCAFE Parameters | 5 | 0 | 0 | 0 | 5 | 2 | 0 | 1 |
| 9 Software Verification and Encryption Requirements | 12 | 9 | 0 | 0 | 22 | 2 | 1 | 8 |
| -- 9.1 General Requirements on SDSC | 6 | 5 | 0 | 0 | 12 | 1 | 1 | 5 |
| -- -- 9.1.2 SDSC Sanity Check | 6 | 5 | 0 | 0 | 12 | 1 | 1 | 5 |
| -- 9.2 Software Verification | 6 | 4 | 0 | 0 | 10 | 1 | 0 | 5 |
| 10 Non-volatile server memory programming complete flow | 8 | 4 | 0 | 0 | 13 | 4 | 1 | 5 |
| 11 Normative references | 0 | 0 | 0 | 0 | 5 | 3 | 2 | 1 |
| Artifact | Type | Caption | Page | Related Requirements | Impact |
|---|---|---|---|---|---|
| TABLE-CVS1232-0001 | Table | Table 1: Definition of terms | page 6 | RFQX-CVS123-2-0026; RFQX-CVS123-2-0018; RFQX-CVS123-2-0028; RFQX-CVS123-2-0126 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0002 | Table | Table 2: Abbreviated terms | page 7 | RFQX-CVS123-2-0031 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0003 | Table | Table 3: Services support due to SUV2 | page 23 | RFQX-CVS123-2-0192; RFQX-CVS123-2-0196; RFQX-CVS123-2-0197; RFQX-CVS123-2-0198; RFQX-CVS123-2-0199; RFQX-CVS123-2-0193; RFQX-CVS123-2-0194; RFQX-CVS123-2-0195 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0004 | Table | Table 4: Routine identifiers for non-volatile memory access | page 24 | RFQX-CVS123-2-0200; RFQX-CVS123-2-0201; RFQX-CVS123-2-0203; RFQX-CVS123-2-0202; RFQX-CVS123-2-0199; RFQX-CVS123-2-0173; RFQX-CVS123-2-0267 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0005 | Table | Table 5: Service 0x34 Request Format | page 25 | RFQX-CVS123-2-0213; RFQX-CVS123-2-0208; RFQX-CVS123-2-0209; RFQX-CVS123-2-0210; RFQX-CVS123-2-0211; RFQX-CVS123-2-0212; RFQX-CVS123-2-0214 | Software update or memory programming context |
| TABLE-CVS1232-0006 | Table | Table 6: Service 0x34 Positive Response Format | page 26 | RFQX-CVS123-2-0214; RFQX-CVS123-2-0215; RFQX-CVS123-2-0216; RFQX-CVS123-2-0217; RFQX-CVS123-2-0218; RFQX-CVS123-2-0219; RFQX-CVS123-2-0220 | Software update or memory programming context |
| TABLE-CVS1232-0007 | Table | Table 7: Service 0x34 dataFormatIdentifier Format | page 26 | RFQX-CVS123-2-0220; RFQX-CVS123-2-0216; RFQX-CVS123-2-0217; RFQX-CVS123-2-0218; RFQX-CVS123-2-0219; RFQX-CVS123-2-0223; RFQX-CVS123-2-0222 | Table source context |
| TABLE-CVS1232-0008 | Table | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format | page 27 | RFQX-CVS123-2-0223; RFQX-CVS123-2-0222; RFQX-CVS123-2-0224; RFQX-CVS123-2-0225 | Software update or memory programming context |
| TABLE-CVS1232-0009 | Table | Table 9: Service 0x34 lengthFormatIdentifier Format | page 27 | RFQX-CVS123-2-0223; RFQX-CVS123-2-0221; RFQX-CVS123-2-0222; RFQX-CVS123-2-0224; RFQX-CVS123-2-0225; RFQX-CVS123-2-0226; RFQX-CVS123-2-0227 | Table source context |
| TABLE-CVS1232-0010 | Table | Table 10: Service 0x37 Request Format | page 28 | RFQX-CVS123-2-0231; RFQX-CVS123-2-0228; RFQX-CVS123-2-0229; RFQX-CVS123-2-0230; RFQX-CVS123-2-0232; RFQX-CVS123-2-0233 | Table source context |
| TABLE-CVS1232-0011 | Table | Table 11: Service 0x37 Positive Response Format | page 28 | RFQX-CVS123-2-0231; RFQX-CVS123-2-0228; RFQX-CVS123-2-0229; RFQX-CVS123-2-0230; RFQX-CVS123-2-0232; RFQX-CVS123-2-0233; RFQX-CVS123-2-0234; RFQX-CVS123-2-0235 | Table source context |
| TABLE-CVS1232-0012 | Table | Table 12: Routine Support per Diagnostic Session | page 29 | RFQX-CVS123-2-0242; RFQX-CVS123-2-0239; RFQX-CVS123-2-0240; RFQX-CVS123-2-0241; RFQX-CVS123-2-0243 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0013 | Table | Table 13: Routine Support per routineControlType | page 30 | RFQX-CVS123-2-0244; RFQX-CVS123-2-0245; RFQX-CVS123-2-0243; RFQX-CVS123-2-0246; RFQX-CVS123-2-0138 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0014 | Table | Table 14: Routine support for Safe State Conditions | page 30 | RFQX-CVS123-2-0245; RFQX-CVS123-2-0244; RFQX-CVS123-2-0246; RFQX-CVS123-2-0247; RFQX-CVS123-2-0248; RFQX-CVS123-2-0138 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0015 | Table | Table 15: Routine 0x2202 Request Format | page 31 | RFQX-CVS123-2-0251; RFQX-CVS123-2-0252; RFQX-CVS123-2-0250; RFQX-CVS123-2-0249 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0016 | Table | Table 16: Routine 0x2202 Positive Response Format | page 31 | RFQX-CVS123-2-0252; RFQX-CVS123-2-0251; RFQX-CVS123-2-0250; RFQX-CVS123-2-0254 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0017 | Table | Table 17: Routine 0x2202 routineStatus routineResult Format | page 32 | RFQX-CVS123-2-0255; RFQX-CVS123-2-0252; RFQX-CVS123-2-0253; RFQX-CVS123-2-0254; RFQX-CVS123-2-0256; RFQX-CVS123-2-0257; RFQX-CVS123-2-0258; RFQX-CVS123-2-0259 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0018 | Table | Table 18: Routine 0xFF00 Request Format | page 33 | RFQX-CVS123-2-0262; RFQX-CVS123-2-0263; RFQX-CVS123-2-0261 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0019 | Table | Table 19: Routine 0xFF00 Positive Response Format | page 33 | RFQX-CVS123-2-0263; RFQX-CVS123-2-0264; RFQX-CVS123-2-0265 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0020 | Table | Table 20: Routine 0xFF00 addressAndLengthFormatIdentifier Format | page 34 | RFQX-CVS123-2-0266; RFQX-CVS123-2-0264; RFQX-CVS123-2-0268; RFQX-CVS123-2-0265; RFQX-CVS123-2-0267; RFQX-CVS123-2-0269; RFQX-CVS123-2-0172; RFQX-CVS123-2-0173 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0021 | Table | Table 21: Module to Index Mapping | page 34 | RFQX-CVS123-2-0266; RFQX-CVS123-2-0268; RFQX-CVS123-2-0267; RFQX-CVS123-2-0269; RFQX-CVS123-2-0172; RFQX-CVS123-2-0173; RFQX-CVS123-2-0197; RFQX-CVS123-2-0199 | State-machine or transition behavior |
| TABLE-CVS1232-0022 | Table | Table 22: Routine 0xFF00 routineStatus routineResult Format | page 34 | RFQX-CVS123-2-0268; RFQX-CVS123-2-0266; RFQX-CVS123-2-0267; RFQX-CVS123-2-0269; RFQX-CVS123-2-0270; RFQX-CVS123-2-0271; RFQX-CVS123-2-0272; RFQX-CVS123-2-0273 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0023 | Table | Table 23: Routine 0xFF01 Request Format | page 35 | RFQX-CVS123-2-0281; RFQX-CVS123-2-0275; RFQX-CVS123-2-0276; RFQX-CVS123-2-0277; RFQX-CVS123-2-0278; RFQX-CVS123-2-0279; RFQX-CVS123-2-0280; RFQX-CVS123-2-0283 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0024 | Table | Table 24: Routine 0xFF01 Positive Response Format | page 36 | RFQX-CVS123-2-0282; RFQX-CVS123-2-0283; RFQX-CVS123-2-0284; RFQX-CVS123-2-0285 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0025 | Table | Table 25: Routine 0xFF01 routineStatus routineResult Format | page 36 | RFQX-CVS123-2-0285; RFQX-CVS123-2-0283; RFQX-CVS123-2-0284; RFQX-CVS123-2-0287; RFQX-CVS123-2-0288; RFQX-CVS123-2-0289; RFQX-CVS123-2-0290; RFQX-CVS123-2-0291 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0026 | Table | Table 26: Routine 0xCAFE Request Format | page 39 | RFQX-CVS123-2-0309; RFQX-CVS123-2-0308; RFQX-CVS123-2-0310; RFQX-CVS123-2-0307; RFQX-CVS123-2-0311; RFQX-CVS123-2-0304; RFQX-CVS123-2-0305; RFQX-CVS123-2-0306 | Diagnostic parameter or service behavior |
| TABLE-CVS1232-0027 | Table | Table 27: Routine 0xCAFE Positive Response Format | page 39 | RFQX-CVS123-2-0309; RFQX-CVS123-2-0308; RFQX-CVS123-2-0310; RFQX-CVS123-2-0307; RFQX-CVS123-2-0311; RFQX-CVS123-2-0312 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS1232-0001 | Diagram | Figure 1: Overview of relation between specifications | page 5 | RFQX-CVS123-2-0017; RFQX-CVS123-2-0015; RFQX-CVS123-2-0016 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS1232-0002 | Diagram | Figure 2: Programming Phase #1 - Pre-Programming Step | page 13 | RFQX-CVS123-2-0081; RFQX-CVS123-2-0082; RFQX-CVS123-2-0083; RFQX-CVS123-2-0084 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS1232-0003 | Diagram | Figure 3: Programming phase #1 – Programming step | page 16 | RFQX-CVS123-2-0110; RFQX-CVS123-2-0114; RFQX-CVS123-2-0111; RFQX-CVS123-2-0112; RFQX-CVS123-2-0113; RFQX-CVS123-2-0115; RFQX-CVS123-2-0116; RFQX-CVS123-2-0109 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS1232-0004 | Diagram | Figure 4: Programming phase #1 – Post-Programming step | page 19 | RFQX-CVS123-2-0146; RFQX-CVS123-2-0147; RFQX-CVS123-2-0149; RFQX-CVS123-2-0144; RFQX-CVS123-2-0145; RFQX-CVS123-2-0148 | Software update or memory programming context |
| DIAGRAM-CVS1232-0005 | Diagram | Figure 5: diagram for signing of software update results | page 38 | RFQX-CVS123-2-0303; RFQX-CVS123-2-0299; RFQX-CVS123-2-0300; RFQX-CVS123-2-0301; RFQX-CVS123-2-0302; RFQX-CVS123-2-0304; RFQX-CVS123-2-0295; RFQX-CVS123-2-0296 | Diagnostic parameter or service behavior |
| DIAGRAM-CVS1232-0006 | Diagram | Figure 6: Erased-only bytes of a memory module | page 41 | RFQX-CVS123-2-0330; RFQX-CVS123-2-0331; RFQX-CVS123-2-0332; RFQX-CVS123-2-0333; RFQX-CVS123-2-0328; RFQX-CVS123-2-0329; RFQX-CVS123-2-0334; RFQX-CVS123-2-0335 | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0007 | Diagram | Figure 7 – Received ECU Memory Layout | page 47 | None | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0008 | Diagram | Figure 8 – Memory layout | page 47 | RFQX-CVS123-2-0348; RFQX-CVS123-2-0347; RFQX-CVS123-2-0350 | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0009 | Diagram | Figure 9 – Resulting SDSC content transmitted using EMP | page 48 | None | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0010 | Diagram | Figure 10 - Verification Entry for Module C | page 49 | None | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0011 | Diagram | Figure 11 – Memory layout | page 50 | RFQX-CVS123-2-0350; RFQX-CVS123-2-0348; RFQX-CVS123-2-0347 | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0012 | Diagram | Figure 12 – Resulting SDSC content | page 51 | None | Security protocol or cryptographic context |
| DIAGRAM-CVS1232-0013 | Diagram | Figure 13 – Memory layout | page 52 | None | Security protocol or cryptographic context |
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| RFQX-CVS123-2-0286 | 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 | 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 |
| RFQX-CVS123-2-0023 | 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 | 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. shall be implemented in the boot software code. 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. It must be clearly separated from the application software. For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. Application software module Contains all vehicle functions required for the normal server operation. The value of this variable may be used by the application to determine whether or not initialization is required. 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. 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. |
| RFQX-CVS123-2-0035 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| RFQX-CVS123-2-0053 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. |
| RFQX-CVS123-2-0075 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| RFQX-CVS123-2-0153 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| RFQX-CVS123-2-0182 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| RFQX-CVS123-2-0183 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| RFQX-CVS123-2-0206 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. |
| RFQX-CVS123-2-0322 | 81 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; blocks SSR derivation | 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. |
| Open Point | Priority | Question | Impact | Status |
|---|---|---|---|---|
| OP-001 | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | TARA scope and effort stay open; downstream assets, goals and design may rework. | Open | |
| 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 | |
| OP-009 | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case. | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. | Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Open |
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-BOOT-001 | Secure software update and flash readiness — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0037; RFQX-CVS123-2-0072 | no | Blocked by Customer Clarification |
| SSR-BOOT-002 | Secure software update and flash readiness — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure (Hardware domain; allocated to Hardware Platform). | RFQX-CVS123-2-0039; RFQX-CVS123-2-0258 | no | Candidate |
| SSR-BOOT-003 | Bootloader and Application State Handling — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (System domain; allocated to System Core). | RFQX-CVS123-2-0044 | no | Candidate |
| SSR-BOOT-004 | Bootloader and Application State Handling — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (IT / backend domain; allocated to Backend and IT Systems). | RFQX-CVS123-2-0055 | no | Blocked by Customer Clarification |
| SSR-BOOT-005 | Bootloader and Application State Handling — Bootloader and Application State Handling | The ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure (Software domain; allocated to Application Software). | RFQX-CVS123-2-0179 | no | Ready for Customer Alignment |
| SSR-COM-002 | Secure Communication and Boundary Control — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (System domain; allocated to System Core). | RFQX-CVS123-2-0173 | no | Candidate |
| SSR-COM-006 | Secure Communication and Boundary Control — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals (Software domain; allocated to Application Software). | RFQX-CVS123-2-0211 | no | Ready for Customer Alignment |
| SSR-COM-009 | 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 (IT / backend domain; allocated to Backend and IT Systems). | RFQX-CVS123-2-0241 | no | Blocked by Customer Clarification |
| SSR-CON-002 | Cybersecurity Concept and Evidence — Cybersecurity Concept and Evidence | The supplier shall produce and maintain the cybersecurity concept and verification evidence covering Cybersecurity Concept and Evidence (Cybersecurity domain; allocated to Security Services; security capability: Cybersecurity requirement handling; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0196; RFQX-CVS123-2-0201; RFQX-CVS123-2-0243 | no | Ready for Customer Alignment |
| SSR-DAI-003 | Data Authenticity and Integrity Verification — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data (IT / backend domain; allocated to Backend and IT Systems). | RFQX-CVS123-2-0240; RFQX-CVS123-2-0279; RFQX-CVS123-2-0297 | no | Ready for Customer Alignment |
| SSR-DAI-004 | Data Authenticity and Integrity Verification — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data (Software domain; allocated to Application Software). | RFQX-CVS123-2-0061; RFQX-CVS123-2-0110; RFQX-CVS123-2-0246; RFQX-CVS123-2-0277; RFQX-CVS123-2-0278; RFQX-CVS123-2-0337 | no | Ready for Customer Alignment |
| SSR-DAI-005 | Security evidence and traceability — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Security evidence and traceability data and reject manipulated or unauthenticated data (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0285 | no | Ready for Customer Alignment |
| SSR-DIAG-002 | Diagnostic Services — Diagnostic Services | The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0046; RFQX-CVS123-2-0251 | no | Ready for Customer Alignment |
| SSR-HW-001 | Hardware / HSM / Secure Storage — Hardware / HSM / Secure Storage | The ECU hardware shall provide the platform and secure-storage capabilities required for Hardware / HSM / Secure Storage (Hardware domain; allocated to Hardware Platform; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0316; RFQX-CVS123-2-0334 | no | Ready for Customer Alignment |
| SSR-RBAC-001 | Secure Diagnostics / RBAC — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model (Cybersecurity domain; allocated to Security Services; security capability: Diagnostic security; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0034; RFQX-CVS123-2-0047; RFQX-CVS123-2-0052; RFQX-CVS123-2-0056; RFQX-CVS123-2-0166; RFQX-CVS123-2-0192; RFQX-CVS123-2-0242; RFQX-CVS123-2-0303 | no | Blocked by Customer Clarification |
| SSR-RBAC-002 | Secure software update and flash readiness — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Secure software update and flash readiness, restricting security-relevant diagnostic services per the OEM-agreed role model (Cybersecurity domain; allocated to Security Services; security capability: Authentication). | RFQX-CVS123-2-0078; RFQX-CVS123-2-0079; RFQX-CVS123-2-0244 | no | Blocked by Customer Clarification |
| SSR-SDT-001 | Secure Data Transfer / Data Security Container — Secure Data Transfer / Data Security Container | The ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme (Software domain; allocated to Application Software). | RFQX-CVS123-2-0114; RFQX-CVS123-2-0204; RFQX-CVS123-2-0247; RFQX-CVS123-2-0261 | no | Ready for Customer Alignment |
| SSR-SDT-002 | Secure Data Transfer / Data Security Container — Secure Data Transfer / Data Security Container | The ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme (Hardware domain; allocated to Hardware Platform). | RFQX-CVS123-2-0350 | no | Ready for Customer Alignment |
| SSR-SYS-001 | System Function — System Function | The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (System domain; allocated to System Core; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0036; RFQX-CVS123-2-0051; RFQX-CVS123-2-0175; RFQX-CVS123-2-0176; RFQX-CVS123-2-0193; RFQX-CVS123-2-0268; RFQX-CVS123-2-0275; RFQX-CVS123-2-0294; RFQX-CVS123-2-0317; RFQX-CVS123-2-0340; RFQX-CVS123-2-0341; RFQX-CVS123-2-0342 | no | Candidate |
| SSR-SYS-002 | System Function — System Function | The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (Process / compliance domain; allocated to Compliance Process; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0320 | no | Candidate |
| SSR-SYS-003 | System Function — System Function | The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0058; RFQX-CVS123-2-0059; RFQX-CVS123-2-0066; RFQX-CVS123-2-0068; RFQX-CVS123-2-0168; RFQX-CVS123-2-0177; RFQX-CVS123-2-0181; RFQX-CVS123-2-0266; RFQX-CVS123-2-0319; RFQX-CVS123-2-0331 | no | Candidate |
| SSR-TOOL-002 | Tooling / IT / Evidence Storage — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0112; RFQX-CVS123-2-0169; RFQX-CVS123-2-0186; RFQX-CVS123-2-0200; RFQX-CVS123-2-0209; RFQX-CVS123-2-0220; RFQX-CVS123-2-0222; RFQX-CVS123-2-0225; RFQX-CVS123-2-0226; RFQX-CVS123-2-0228; RFQX-CVS123-2-0232; RFQX-CVS123-2-0233; RFQX-CVS123-2-0235; RFQX-CVS123-2-0237; RFQX-CVS123-2-0238; RFQX-CVS123-2-0250; RFQX-CVS123-2-0254; RFQX-CVS123-2-0262; RFQX-CVS123-2-0263; RFQX-CVS123-2-0265; RFQX-CVS123-2-0273; RFQX-CVS123-2-0276; RFQX-CVS123-2-0281; RFQX-CVS123-2-0282; RFQX-CVS123-2-0284; RFQX-CVS123-2-0292; RFQX-CVS123-2-0295; RFQX-CVS123-2-0298; RFQX-CVS123-2-0302; RFQX-CVS123-2-0308; RFQX-CVS123-2-0309; RFQX-CVS123-2-0310; RFQX-CVS123-2-0311; RFQX-CVS123-2-0313; RFQX-CVS123-2-0323; RFQX-CVS123-2-0325; RFQX-CVS123-2-0329 | no | Blocked by Customer Clarification |
| SSR-TOOL-003 | Tooling / IT / Evidence Storage — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage (Software domain; allocated to Application Software). | RFQX-CVS123-2-0167; RFQX-CVS123-2-0190; RFQX-CVS123-2-0203; RFQX-CVS123-2-0205; RFQX-CVS123-2-0213; RFQX-CVS123-2-0214; RFQX-CVS123-2-0215; RFQX-CVS123-2-0218; RFQX-CVS123-2-0223; RFQX-CVS123-2-0224; RFQX-CVS123-2-0227; RFQX-CVS123-2-0229; RFQX-CVS123-2-0230; RFQX-CVS123-2-0234; RFQX-CVS123-2-0239; RFQX-CVS123-2-0256; RFQX-CVS123-2-0260; RFQX-CVS123-2-0269; RFQX-CVS123-2-0328; RFQX-CVS123-2-0336; RFQX-CVS123-2-0339 | no | Ready for Customer Alignment |
| SSR-UPD-001 | Secure software update and flash readiness — Software Update / Flashing | The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0042; RFQX-CVS123-2-0048; RFQX-CVS123-2-0049; RFQX-CVS123-2-0050; RFQX-CVS123-2-0178; RFQX-CVS123-2-0184; RFQX-CVS123-2-0188; RFQX-CVS123-2-0197; RFQX-CVS123-2-0199; RFQX-CVS123-2-0299; RFQX-CVS123-2-0333 | no | Blocked by Customer Clarification |
| SSR-UPD-002 | Secure software update and flash readiness — Software Update / Flashing | The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (System domain; allocated to System Core; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0043; RFQX-CVS123-2-0062; RFQX-CVS123-2-0064; RFQX-CVS123-2-0070; RFQX-CVS123-2-0071; RFQX-CVS123-2-0185; RFQX-CVS123-2-0271 | no | Blocked by Customer Clarification |
| SSR-UPD-003 | Secure software update and flash readiness — Software Update / Flashing | The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0164; RFQX-CVS123-2-0187 | no | Blocked by Customer Clarification |
| SSR-UPD-004 | Secure software update and flash readiness — Software Update / Flashing | The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence (Hardware domain; allocated to Hardware Platform; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0165 | no | Candidate |
| SSR-VV-002 | Security evidence and traceability — Verification and Validation | The supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan (IT / backend domain; allocated to Backend and IT Systems; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0207; RFQX-CVS123-2-0335 | no | Ready for Customer Alignment |
| SSR-VV-003 | Security evidence and traceability — Verification and Validation | The supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan (Software domain; allocated to Application Software; interface: OEM/Customer Review Interface). | RFQX-CVS123-2-0216; RFQX-CVS123-2-0217; RFQX-CVS123-2-0326 | no | Ready for Customer Alignment |