Supplier Proposal Summary
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Search
Last updated: 2026-06-25 12:57
RTRFQX Review TeamWorkspace
Supplier Proposal Summary
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Takeaway
The supplier proposal summary is suitable for customer review, but it is not an agreed baseline. Decision risk is concentrated in shared cybersecurity ownership, customer-owned infrastructure, and assumption-based implementation scope.
- Confirm assumptions before converting accepted-with-assumption items into fixed scope.
- Use open points to close diagnostics, update, PKI, SecOC/SDT, and DIA/RASIC responsibilities.
- Keep informational items out of effort scope unless the customer makes them binding.
Accept145Confirm responsibility & method
Accept with Assumption309Confirm assumption
Partially Accept240Confirm responsibility split
Customer Clarification211Answer open point
Informational Only819Confirm if binding
Executive Proposal Summary
| Supplier Position | Count | Meaning | Customer Action Needed |
|---|---|---|---|
| Accept | 145 | Supplier will implement. | Confirm responsibility & method |
| Accept with Assumption | 309 | Implement under stated assumption. | Confirm assumption |
| Partially Accept | 240 | ECU part only; OEM part to confirm. | Confirm responsibility split |
| Needs Customer Clarification | 211 | Blocked pending answer. | Answer open point |
| Needs Internal Review | 2 | Supplier reviewing internally. | None yet |
| Informational Only | 819 | Context only. | Confirm if binding |
Implementation Proposal by Security Capability
| Security Capability | Related Requirements | Supplier Proposal | Customer Dependency |
|---|---|---|---|
| Diagnostic security | 24 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Cybersecurity requirement handling | 21 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Authentication | 16 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Certificate handling | 16 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Key management | 14 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Vulnerability management | 2 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Incident response | 1 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Logging and audit trail | 1 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Secure communication | 1 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
Proposals by Supplier Position
Accepted Requirements (145)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| RFQX-1001379436-P10-000-01-0038 | Data specified by the vehicle manufacturer shall be protected from manipulations. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-1001379436-P10-000-01-0039 | Data specified by the vehicle manufacturer shall be protected from disclosure. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-1001379436-P10-000-01-0040 | Intellectual property of the vehicle manufacturer shall be protected from disclosure. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-1001379436-P10-000-01-0060 | An ECU returned from field shall allow for field-return analysis. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-1001379436-P10-000-01-0062 | An ECU enabled for field-return analysis shall not be possible to use as a spare part. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0002 | The clutch actuator shall be electrically driven | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0004 | The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0013 | The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components. Details to be agreed with Traton | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0014 | The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0021 | The total stroke of the actuator shall be 85 mm | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0022 | The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. Dimensions measured on the ECA. See Figure 3 - Pushrod positions. Figure 3 - Pushrod positions | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0025 | When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided. The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0027 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope -1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0029 | The ECA shall be adapted for 2 pcs 10 mm guide pins Figure 5 - Gearbox flange | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0030 | The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep. The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. Both depths measured from the center of the oval hole in the Gearbox/ECA flange. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0032 | The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0043 | If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0047 | The actuator shall apply a preload force for the release bearing. The preload force measured on the push rod shall be 150N to 250N independent of the clutch position | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0049 | It must be possible to assemble the actuator independent of the lever position without any power connection. This means that the push rod shall be possible to move by hand. Maximum force allowed is 300N. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0052 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to ,and max speed set to 125mm/s (see | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0055 | P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see ). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0057 | The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0058 | It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req. 6.5). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0059 | The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0060 | The actuator must be able to determine the pushrod position according to the following Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm. Resolution (smallest discernible unit of change along the X axis): 0.0125mm. Repeatability (maximum variation between measurements at the same position and in the same unit, with equal environmental conditions): +/- 0.1mm. Range: 85mm (AP) | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0062 | The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0070 | Maximum overshoot is 0.2 mm When a new position is requested, but the stroke is too short to reach requested speed, the ECA shall complete the stroke in minimum time with dynamic in compliance with the , 5.2 and this section. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0071 | Req. 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. Step from FCCP to 0.5x fully open position Wait 2 seconds Step to fully open position Wait 2 seconds Step to 0.5x fully open position Wait 2 seconds Step to FCCP Figure 10 - Step response test cycle | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0074 | The test shall be done with the highest operating temperature (see ) and maximum clutch force (See Appendix A) Figure 11 - Release frequency test | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0075 | It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min. This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. 8.1). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0101 | The ECA shall report a unique ECA individual identification number | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0105 | The ECA shall report its current System State. Valid states are explained in requirements 6.14.1 - 6.14.9. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0110 | This value shall be sent when the ECA is actuating Absolute Position Control. 0x1 | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0111 | This value shall be sent when the ECA is actuating Relative Position Control. 0x2 | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0112 | This value shall be sent when the ECA is actuating Torque Control. The torque being controlled is the torque of the motor. 0x4 | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0113 | This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e. passing FCCP). 0x5 | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0114 | This value shall be sent when the ECA is performing its initiation routine and is not yet available for control. 0xA | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0116 | This value shall be sent when the actuator is performing a motor brake simulation. 0xD | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0119 | The ECA shall report the current system temperature.(Ref 14.14) | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0120 | The ECA shall calculate and report the actuator motor torque. (Ref 14.14) | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0122 | The ECA shall report the current system voltage. (input voltage) (Ref 14.14) | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0123 | The ECA shall store and report its accumulated operational hours. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0124 | The ECA shall report its accumulated lifetime travel length. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0138 | There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0143 | The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot through”) is avoided. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0145 | A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss. Relates to Safety Goals set in PD3339794 (Ref 14.16). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0146 | All external electrical connectors shall be geometrically coded. If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0154 | The ECA is connected directly to the battery GND (31). This ground connection will act as system ground and reference for the entire ECA. The ground shall not be DC connected to the ECA housing. Requirements Power cable dimension: Operating parameters Remark Min Typ. Max. Unit | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0198 | The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0199 | The ECA must be maintenance free over the whole life time | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0200 | The maintenance window cover (See req. 4.17) shall be provided as a spare part | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0201 | In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing. It is allowed to destroy the ECA in the process. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0208 | All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval. For type approval, the vehicle and its components shall comply with ECE Regulation No. 105 and with European Directive 2008/68/EC, as amended. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0213 | The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0214 | The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-3299216-1-0218 | For this unit, the following definitions of test procedure I and test procedure II shall be used Test procedure I A comprehensive test where all functional requirements are verified. This test shall be performed before and after exposure. Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified. This test shall be possible to perform during exposure. Reduced versions of test procedure II may be agreed and used during various tests. Alternative 1: Test cycle according to Appendix B, frequency 10 to 30 strokes per minute. Alternative 2: Release frequency test according to req. 5.12. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility & method |
| RFQX-3299216-1-0245 | CVS40 §8.1 TS-01 Flammability In order to fulfil flammability demands, any plastic materials (i.e. tab headers) shall be made of self- extinguishing materials (i.e. UL94). Y | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS123-2-0036 | All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0058 | Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0059 | The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0167 | It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0168 | Application software and application data modules shall be programmable in any order. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0175 | The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0176 | The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0177 | It shall be possible to program the same software version repeatedly. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0186 | A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0190 | The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0200 | The server shall support the routines specified in Table 4. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0209 | The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0220 | The server shall support parameter dataFormatIdentifier formatted according to Table 7. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0222 | The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0225 | The server shall support positive response formatted according to ISO14229-1:2020. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0226 | If for any reason an error occurs during decryption of data, the server shall return NRC 0x10. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0228 | The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0232 | The server shall not support transferRequestParameterRecord parameter. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0233 | The server shall not support transferResponseParameterRecord parameter. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0235 | The server shall support request formatted according to ISO14229-1:2020. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0237 | The server shall support positive response formatted according to ISO14229-1:2020. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0238 | The server shall support negative response codes according to CVS32. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0241 | The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0250 | The server shall support the routine request according to Table 15. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0251 | Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response The server shall support the routine positive response according to Table 16. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0254 | The server shall support parameter routineStatus routineResult formatted according to Table 17. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0262 | The server shall support the routine request according to Table 18. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0263 | The server shall support the routine positive response according to Table 19. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0265 | The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0266 | E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0268 | When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0273 | The server shall check whether the individual modules are complete and compatible with one another. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0276 | The consistency check shall be carried out solely by the server. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0281 | The server shall support the routine request according to Table 23. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0282 | The server shall support the routine positive response according to Table 24. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0284 | The server shall support parameter routineStatus routineResult formatted according to Table 25. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0292 | The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0294 | The hash algorithm shall be SHA512. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0298 | The server shall return in the parameter routineResultProof the signed hash. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0302 | Once a SDSC has being accepted by the server, the server shall store in the NVM the receipt number sent over as part of the EMP request. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0308 | The server shall support the routine request according to Table 26. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0310 | The server shall support the routine negative response according to CVS33. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0313 | The server shall implement SDSC structure as defined in CVS154. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0316 | The range start field shall be the memory address offset from the dataLocator field. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0317 | The range length field shall be the number of bytes to be verified. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0320 | The vehicle manufacturer shall review and accept the proposals for every dataLocator. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0323 | Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0325 | If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0328 | Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0329 | The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0331 | When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation. | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS123-2-0336 | If NOT_OK is returned, the server shall not accept the new software for execution. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0339 | For the received data, where a match is found in the EncryptionEntry of the DSC, the server shall initialize a cipher if not previously initialized. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0340 | An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0341 | The cipher shall be reinitialized for each new Encryption entry. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS123-2-0342 | According to best practise received data shall be decrypted “on the fly” before storing to NVM. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility & method |
| RFQX-CVS124-0352 | 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & & | Accept with assumption. Implement ECU-side 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. | Confirm responsibility & method |
| RFQX-CVS154-0008 | The server shall support a DSC Metadata block containing version and id fields. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS154-0009 | The server shall support the Major and Minor version as specified in 3.2. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS154-0011 | The server shall support a DSC containing encryptionEntries. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS154-0012 | The server shall support a DSC containing itemEntries. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS154-0014 | The server shall expect an ASN.1 SEQUENCE tag with length zero for encryptionEntries that contains no EncryptionEntry items in a DSC transmitted by the client. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
| RFQX-CVS154-0015 | The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntries that contains no items in a DSC transmitted by the client. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility & method |
Open the requirement review register for the remaining 25 rows.
Accepted with Assumptions (309)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| RFQX-1001379436-P10-000-01-0007 | The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0008 | The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0012 | The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0013 | All risks identified in cybersecurity risk analyses shall be evaluated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0015 | Cybersecurity controls shall sufficiently reduce the risk. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0017 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0018 | The supplier shall provide documentation of the verification and validation methods of cybersecurity features. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0019 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0021 | An inventory of software and protocols, including their versions, shall be provided by the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0022 | A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0024 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0025 | The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0027 | The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0028 | Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0029 | All network services implemented in the ECU shall undergo hardening. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0030 | The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0031 | Communication interfaces shall use boundary controls such as ingress/egress filtering. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0032 | Communication boundary controls shall be configurable by the vehicle manufacturer. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0034 | Any interfaces used for development purposes shall be removed or disabled in series production. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0037 | It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0042 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0043 | ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0044 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0045 | It shall be possible to update the software of the ECU. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0046 | The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0047 | An incident response process shall be proposed to and approved by the vehicle manufacturer. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0048 | In case of cybersecurity incidents, the incident response process shall be used. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0049 | The incident response process shall be maintained for the entire product lifetime. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0050 | The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0051 | Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0055 | Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0058 | The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0059 | Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0061 | Field-return analysis secrets shall not be operational in the field. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-1001379436-P10-000-01-0067 | Security related events shall be identified and logged. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0007 | The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17). The variant type shall be based on delivery agreement and Brand involved. Variant 1: For Scania units, wordmark variant C1 Part number (7 digits). Variant 2: For MAN units, wordmark variant Z1. Part number (13 digits). Variant 3: For International units, wordmark variant X1. Part number (8 digits) Variant 4 Tentik wordmark variant W. Part number (9 digits, two spaces in format: 12 345 6789). Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information. The marking shall not be visible when the ECA is mounted on a gearbox. The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0012 | The rubber cover (See req. 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm. Date dial: CVM. Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-3299216-1-0026 | The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435 | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0031 | The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. 4.22) up to 50 times. The clutch load will be removed and the screw interface tightened between every load occasion. Surface indents in the contacts are allowed as long as the structural integrity is unaffected | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0034 | The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0035 | The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. 4.4). | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0042 | The connector for communication and power shall be positioned as indicated in Figure 4 ISO view of 3D envelope, when connected. Details regarding actual length and positioning tolerances shall be agreed in design phase. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0061 | For each stroke that the actuator performs it shall adjust to the current wear of the clutch. This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req. 5.10. The implementation can be either a pure mechanical solution or it can be implemented using a software based solution. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0083 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). The RP can in this mode correspond to the full wear travel of the clutch (see req. 4.3) It is allowed to control movement to protect the ECA and clutch from hardware damage. Specific cases shall be approved with Traton. Control mode Absolute position 0x01 | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0084 | Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP). The RP can be up to a full Release Travel (22,4 mm) in this mode. How the FCCP can be identified is described in 6.5. When RP = 0 the actuator is allowed to have a position that is less than the FCCP but not more, since this would open the clutch. Control mode Relative position 0x02 | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0089 | The value shall be frozen at the last identified position and used for RPC. Self-adjustment disabled 0x3 | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0102 | The ECA shall report supplier code 5 via CAN. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0103 | The ECA shall report a complete SW version number. The number is decided by the supplier and can be in the range 0-64255. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0104 | The ECA shall report a complete HW version number. The number is decided by the supplier and can be in the range 0-64255. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0107 | 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see , | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-3299216-1-0115 | This value shall be sent when the actuator is in debug or test control state. 0xC | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0121 | The ECA shall report the current for each phase of the actuator. These values shall be calculated using a moving mean filter. The filter time shall equal the update frequency . (Ref 14.14) | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0125 | CVS120 shall be applied (Ref 14.12). | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-3299216-1-0126 | Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. The following apply: Mandatory: TRATON secure updates - CVS31,CVS32,CVS123-2,CVS154 TRATON secure diagnostics - CVS31,CVS32,CVS151 TRATON Specification on Unified diagnostic Services CVS124 Other applicable documents considered as supporting specifications: CVS30, CVS33, CVS34,CVS121,CVS122,SecureBoot,Vehicle Baseline Requirements, ECU Baseline Requirements Additional standards/documents will be made available, if applicable. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-3299216-1-0134 | The reported ESD must be able to be validated and invalidated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0135 | The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc. One unique DTC will be set per bit in the ESD signal. If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. Internally stored parameters may be accessible only using supplier defined tools . | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm assumption |
| RFQX-3299216-1-0136 | Any data logged or stored shall be agreed upon together with Traton. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0137 | When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles. The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function. This could be designed with for example data mirroring. It is acceptable if purely statistical data (e.g. operation hours) from the active operation cycle is not stored in case of an abnormal shutdown. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0139 | It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. Handling to be agreed with Traton. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0144 | A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0153 | The ECA can be connected to the battery+ (30) permanently through the system fuse or through a master switch that physically cuts off power. All power used by the ECA shall be taken from this battery connection. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0171 | The ECA has one CAN bus. Any watchdog circuit shall have no influence on the CAN bus The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0172 | The controller and transceiver shall be CAN FD ready Parameter Limit values Unit Remarks Min. Typ. Max. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0177 | The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0178 | CAN shield. Footprint prepared for internal connection to system ground 31_ECA via a resistor and a capacitor in series. The components shall not be populated by default. The CAN front end shall be designed to comply with TB1905. (Ref 14.3) | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0207 | The ECA shall fulfil the requirements stated in STD3868 STD3868 is a comprehensive document referring to several underlying standards. Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list. STD4159, Chemical substances with limited use – Scania Grey list. CVS 83, Material declaration according to Scania IMDS reporting std. The different parts of the housing shall be marked according to material content. The ECA shall be lead free. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0228 | CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors. IP classes to test: IP6K6K, IP6K7, and IP6K9K Y | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-3299216-1-0285 | The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| RFQX-CVS123-2-0037 | The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0039 | an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0043 | Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0044 | Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0048 | The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0049 | The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0051 | The supplier shall document the versioning concept for supplier specific DIDs. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0052 | System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0056 | When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197 | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0062 | Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0064 | The supplier shall deliver the necessary information to verify the integrity of the flash files. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0066 | Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0068 | When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0072 | The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0165 | Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0173 | cannot be met, a compression method shall be implemented. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0178 | If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0179 | Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0181 | If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0184 | After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0185 | The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0192 | Diagnostic services support shall be as per CVS124. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0193 | Additionally, the services specified in Table 3 shall be supported. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0196 | ECU identification data support shall be as per CVS124. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0204 | Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0247 | The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0258 | In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0261 | The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e., the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0271 | This RoutineIdentifier shall be able to execute independent from programming sequence | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0275 | The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS123-2-0319 | The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm assumption |
| RFQX-CVS123-2-0333 | The byte value of an erased data byte (typically FF or 00) depends on the MCU/Flash memory and shall be specified by the software supplier as an input for the hashing process. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0019 | All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0024 | This DID shall be stored under flash memory module in flash memory. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0028 | This DID shall be stored under dataset module stored in flash memory. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0031 | This DID shall be stored under dataset module stored in flash memory. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0036 | Table 13 – Description of DID 0xF18A systemSupplierIdentifierDataIdentifier 0xF18A Name: systemSupplierIdentifierDataIdentifier Byte No Description Format Cvt Byte Value Default Data To be specifie d by the Content and format to be specified by the supplier Should be M : M : 5.2.1.9 DID 0xF18B ECUManufacturingDateDataIdentifier | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0043 | This DID shall be stored under flash memory module in flash memory. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0058 | This DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0060 | This DID shall report a snapshot of the mileage of the vehicle as received on CAN or other ECU-external source at the first reception of the signal with a good signal status after a software update. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0074 | This DID shall be stored under flash memory module in flash memory. | Accept with assumption. Implement ECU-side 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. | Confirm assumption |
| RFQX-CVS124-0075 | A default diagnostic session shall be supported. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0077 | A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0078 | Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0079 | Of a marked service, an execution shall be implemented for the specified session as perTable 39. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0082 | The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0084 | CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0087 | Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0089 | The session transitions stated below shall be possible to request both physically or functionally | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0129 | Project specific DID shall be added to ranges defined as system supplier specific in ISO 14229 | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0130 | Table 41 lists reserved ECU DIDs/DID ranges which are not used for identification and which shall only be implemented in agreement with the vehicle manufacturer. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
| RFQX-CVS124-0132 | These ECUs shall implement the following DIDs according to Table 42. | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm assumption |
Open the requirement review register for the remaining 189 rows.
Partially Accepted Requirements (240)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| RFQX-1001379436-P10-000-01-0036 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-1001379436-P10-000-01-0041 | It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer. | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm responsibility split |
| RFQX-1001379436-P10-000-01-0054 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm responsibility split |
| RFQX-1001379436-P10-000-01-0063 | All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0024 | When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA. The rubber grommet at the lower part of the flange can have the same interface as the surrounding aluminum flange. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0033 | It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA. Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0036 | The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 ISO view of 3D envelope. The maximum force is 1kN. Surface indents are allowed as long as it does not affect other requirements or the structural integrity of the ECA. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0039 | The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. It shall still remain intac t and keep tightness after vibration testing (See req.10.5) | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0040 | When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA. A wire could be used as test object. Figure 6 - Snap in tool space | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-3299216-1-0041 | The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie Optionally an M8 screw thread and rotation stop for a sheet metal bracket indicated in Figure 4 - ISO view of 3D envelope, can be provided. The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0079 | The ECA will be controlled by messages on the CAN bus and by the PWM signal specified in req. 7.24-7.33. The CAN communication messages are specified in PD2497100 (Ref 14.14). It shall be followed to its full extent. If needed, some messages might be complemented with additional checksums and message counters | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0088 | A maximum allowed speed of the actuator is sent as a separate signal on CAN. If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-3299216-1-0181 | The air inside the electronics enclosure shall be ventilated with the use of a membrane. The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane. The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS123-2-0034 | The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0042 | The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0046 | A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0047 | A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0050 | Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data). | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0061 | A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0070 | Programmable servers shall support the full programming sequence described in this chapter. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0071 | Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0078 | To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0079 | The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0110 | For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory). | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0112 | If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0114 | Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0164 | ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0166 | A server that is running in the application shall respond with the same diagnostic address after a switch to boot. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0169 | The server shall be able to update an individual module independently from any other module. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0187 | A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0188 | The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0197 | When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0199 | When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0201 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0203 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0205 | If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24 | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0207 | For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0211 | The server shall not execute the new software until it can be verified using routine 0xFF01. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0213 | The server shall support service request formatted according to Table 5. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0214 | The server shall support service positive response formatted according to Table 6. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0215 | The server shall support service negative response as per ISO14229-1:2020. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0216 | In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0217 | In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0218 | The server shall verify the software hash after decryption and/or decompression are performed. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0223 | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier The server shall support parameter lengthFormatIdentifier formatted according to Table 9. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0224 | The server shall support request formatted according to ISO14229-1:2020. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0227 | The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0229 | The server shall support request formatted according to Table 10. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0230 | The server shall support positive response formatted according to Table 11. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0234 | The server shall support service 0x84 according to CVS32. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0239 | The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0240 | The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0242 | The server shall support the routine in the diagnosticSession according to Table 12. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0243 | The server shall support the routineControlType according to Table 13. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0244 | Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0246 | The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0256 | The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0260 | When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0269 | The server shall support parameter routineStatus routineResult formatted according to Table 22. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0277 | The server shall verify the integrity of the software as a part of the consistency check. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0278 | The integrity information shall be supplied to the server before the software is updated. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0279 | The integrity check shall be carried out solely by the server. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0285 | Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0295 | The server shall sign the hashed output using the receipt-keys. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0297 | The server shall use ED25519 as signature algorithm. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0299 | The client shall send the Servers routineStatus routineResult response to the backend. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0303 | Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: • Routine 0xFF00 Erase Memory | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0309 | Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response The server shall support the routine positive response according to Table 27. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0311 | The server shall support the parameter EMP message according to CVS33. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0326 | The server shall validate each VerificationEntry found in the SDSC. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS123-2-0334 | The server shall be able to verify that erased-only blocks covered in range of memory are erased. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0335 | When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS123-2-0337 | If OK is returned, the server shall accept that installed software is valid in terms of integrity. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0018 | The implementation of the client and the server shall be compliant with ISO 14229-1 with the | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0083 | The server shall implement support for RBAC (Role Based Access Control) based on CVS151. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0088 | The server implementation shall comply with the following state diagram and the following state | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0142 | Before switching to programming session, the server shall ensure the applicable conditions as per Table 76 - Programming preconditions is checked to ensure the vehicle is in safe condition. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS124-0152 | The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0154 | The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0157 | The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0161 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0168 | Servers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0171 | When receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0185 | Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0192 | The server shall be able to switch baud rate within one second. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0193 | The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application. | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0225 | It shall be mandatory to utilize SPNs & FMIs according to SAE J1939. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0270 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0272 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0274 | If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0275 | The server shall support service request formatted according to Table 62. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0306 | Authentication (0x29) service shall be used for authentication of client and server. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0341 | The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0345 | When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0362 | If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0364 | The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0365 | If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed). | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0381 | The server shall check whether or not the individual modules are complete and compatible with | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0384 | The consistency check shall be carried out solely by the server. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0385 | The server shall verify the authenticity and integrity of the software as a part of the consistency check. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0386 | The authenticity and integrity information shall be supplied to the server before the software is updated. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0387 | The authenticity and integrity check shall be carried out solely by the server. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS124-0389 | The server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS124-0397 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP The request and response shall be implemented according to CVS33. | Partially accept. ECU-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. | Confirm responsibility split |
| RFQX-CVS124-0406 | The occurrence counter shall increment if it’s value is not at it’s maximum value already. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0431 | The server shall be available for complete diagnostic communication within two seconds after a power on. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm responsibility split |
| RFQX-CVS124-0433 | for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS124-0434 | For P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0436 | For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0438 | The value for P4_Server_max shall be maximum 30 seconds. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS124-0439 | The system supplier shall document the implemented value for P4_Server_max. | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm responsibility split |
| RFQX-CVS151-0014 | If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0016 | If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0018 | If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0019 | The server shall deny a request if no matching rule is found on RBACC. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0023 | The server shall evaluate each role-configuration independently from each other. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0028 | The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020). | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0030 | The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) } | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm responsibility split |
| RFQX-CVS151-0032 | The server shall support in the version field two octets. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| RFQX-CVS151-0033 | The server shall support major version value 3 and minor version value 0. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
Open the requirement review register for the remaining 120 rows.
Rejected Requirements (0)
None.
Clarification Needed (211)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| RFQX-1001379436-P10-000-01-0009 | Method and scope shall be proposed to and approved by the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0010 | Documentation on the method and results shall be provided to the vehicle manufacturer. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-1001379436-P10-000-01-0011 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Answer open point |
| RFQX-1001379436-P10-000-01-0014 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Answer open point |
| RFQX-1001379436-P10-000-01-0016 | It shall be possible to verify which cybersecurity controls were derived from which requirements. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-1001379436-P10-000-01-0026 | Methods shall be proposed to and approved by the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0033 | Methods shall be proposed and approved by the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0035 | The details shall be agreed upon between the vehicle manufacturer and the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-1001379436-P10-000-01-0052 | The report shall include information needed to identify the affected vehicles/products. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0053 | Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0056 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Answer open point |
| RFQX-1001379436-P10-000-01-0057 | Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0064 | End-of-life and decommissioning shall be specifically considered. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0065 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-1001379436-P10-000-01-0066 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0001 | The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0008 | The variant type shall be based on delivery agreement and Brand involved. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0009 | Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0010 | The marking shall not be visible when the ECA is mounted on a gearbox. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0011 | The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0015 | 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0016 | Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0017 | 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0018 | 2.12 Traton requires: - Documentation of the product, i.e. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0028 | The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0037 | The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0038 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Answer open point |
| RFQX-3299216-1-0044 | If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0045 | Details regarding actual length and positioning tolerances shall be agreed in design phase. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0050 | This means that the push rod shall be possible to move by hand. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0051 | 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0054 | This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Answer open point |
| RFQX-3299216-1-0056 | This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Answer open point |
| RFQX-3299216-1-0063 | This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0064 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0065 | P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0066 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0067 | 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0068 | Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0072 | 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Answer open point |
| RFQX-3299216-1-0073 | P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11 - Release frequency test continuously for 5 hours without any degradation or failure. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Answer open point |
| RFQX-3299216-1-0076 | Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0077 | The strategy shall be disc ussed and approved with Traton. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0078 | This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0081 | P 1 Page 6 SW functionality 6.1 TB4684 shall be applied. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0082 | It shall be followed to its full extent. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0085 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0086 | Specific cases shall be approved with Traton. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0087 | Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0090 | 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0091 | ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0092 | CAN communication shall still be active. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0093 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Answer open point |
| RFQX-3299216-1-0094 | 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0096 | The value of the FCCP shall be reported via CAN(Ref 14.14) Req. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0097 | The value shall be frozen at the last identified position and used for RPC. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0106 | 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0109 | ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults . | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0117 | 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0118 | 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0131 | These values shall be calculated using a moving mean filter. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0132 | The filter time shall equal the update frequency . | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0140 | If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0142 | The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0148 | 7.2 Short circuit protection shall be implemented by hardware. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0149 | If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0150 | 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0160 | All power used by the ECA shall be taken from this battery connection. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0161 | The ground shall not be DC connected to the ECA housing. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0162 | 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0163 | It shall be used to control the power up sequence to the µP. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0164 | The Wake-up signal shall also be connected to a digital input on the µP. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0165 | Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0166 | After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0167 | After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0168 | Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0169 | Redundancies due improper shutdown shall be aligned with Traton. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0170 | If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0174 | Any watchdog circuit shall have no influence on the CAN bus. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0175 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0176 | 7.36 Termination resistance: - 2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s. | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Answer open point |
| RFQX-3299216-1-0179 | The components shall not be populated by default. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0180 | The CAN front end shall be designed to comply with TB1905. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0182 | The quality of the wire bonding and position shall be properly analyzed. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0183 | The material shall be lead free and of ”high temperatures solder type”. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0184 | The melting point of the soldering material and the composition of the soldering material shall be declared by supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0185 | The PCB must be supported and must not bent in any direction during the process. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0186 | Conformal coating or lacquer shall cover the entire PCB and all solder joints. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0187 | The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0188 | shall be specified in the initial offer. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0189 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0190 | HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0191 | Water based and silicone lacquers shall not be used. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0192 | The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0193 | The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0194 | The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0195 | 7.46 Forbidden components: BGA capsule in any form must not be used. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0196 | Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0202 | 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0203 | Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0204 | 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0205 | Spare parts or repair kits shall be defined together in agreement. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0206 | 4.17) shall be provided as a spare part. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0209 | Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0210 | The different parts of the housing shall be marked according to material content. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0211 | The ECA shall be lead free. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0212 | For type approval, the vehicle and its components shall comply with ECE Regulation No. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0215 | CAN communication shall not be affected. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0216 | Memory functions shall remain Class A. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0217 | Accepted behaviour in this case shall be agreed upon between Traton and Supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0219 | This test shall be performed before and after exposure. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0220 | Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Answer open point |
| RFQX-3299216-1-0221 | This test shall be possible to perform during exposure. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0256 | tab headers) shall be made of self- extinguishing materials (i.e. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0279 | P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0280 | The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety". | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0281 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
| RFQX-3299216-1-0282 | For this purpose possible causes must be systematically identified. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0283 | For these analyses at least the methods in ISO 26262 shall be applied. | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Answer open point |
| RFQX-3299216-1-0286 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Answer open point |
Open the requirement review register for the remaining 91 rows.
Customer-Owned / Informational (819)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| RFQX-1001379436-P10-000-01-0006 | Cybersecurity principles are high level requirements that drive development and refinement of functional and technical cybersecurity requirements. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-1001379436-P10-000-01-0020 | The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-1001379436-P10-000-01-0023 | The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0003 | The actuator is placed outside of the gearbox | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0005 | The actuator will be controlled by a position and speed demand by CAN-bus | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0006 | The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0020 | The maximum release stroke is 22,4 mm from FCCP | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0023 | The gearbox flange designated to the ECA has three different surfaces, see Figure 5 Gearbox flange. Surface A, which is machined pressure die cast aluminium that can act both as a heat source and heat sink for the ECA Surface B which is a raw pressure die casted surface. Surface C which is a rubber grommet, that does not require any different interface compared to the surrounding surface A. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0046 | The clutch force acting on the pushrod is defined in Appendix A | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0048 | The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0053 | ) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-3299216-1-0080 | Req. 6.3.1 to 6.3.5 describe the various control modes that can be requested via CAN (Ref 14.14) | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0095 | ). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0098 | Accuracy mode | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0099 | Not applicable. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0100 | Feedback from the ECA will also be sent via CAN. Specific error reporting as per req. 6.13. Message contents to be agreed with Traton | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0108 | ,req. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0127 | Minimum diagnostic feedback described in req. 6.22.1 - 6.22.11. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0128 | Wrong rotation direction | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0129 | Short circuit / open load on the phases | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0130 | Motor rotation feedback, short circuit / open load | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0141 | Internally stored parameters may be accessible only using supplier defined tools . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0147 | 2*6.3mm (MCP) 6*2.8mm (MCP) Code A TE part no.: 1-2299782-1 Pin list with: Pin distribution, Pin size (see req. 7.41) | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0151 | 6.3mm Tin, Sn ≥3 μm thick. ≥1 µm Ni | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0152 | 2.8mm Gold, Au ≥0,8 μm thick. ≥1 µm Ni | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0155 | Power cable length: - - 2*6000 mm | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0156 | A 1. According to ISO 8820-5:2015 SF30 type fuse-links. 2. According to ISO 8820-5:2015 SF51 type fuse-links. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0157 | Umax: - - 32/36/48 A Specific test relations TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0158 | CVS41 limits may go below this value. Valid only for ECU and communication function. For clutch actuation see req. 5.13 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0159 | Figure 133 A 3. Up to 100 kHz | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-3299216-1-0173 | CAN FD: 4000 - - kbit/s Figure 15 - Reference circuit | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-3299216-1-0197 | The life length requirement is minimum 3000 operating hours per year for 15 years | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0222 | Reduced versions of test procedure II may be agreed and used during various tests. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0223 | CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0224 | CVS40 §5.6 TC-06 Thermal shock Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0225 | CVS40 §5.7 TC-07 Splash water test Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0226 | CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0227 | CVS40 §5.9 TC-09 Leakage search test Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0229 | CVS40 §5.11 TC-11 Corrosion in flowing mixed noxious gas N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0230 | CVS40 §5.12 TC-12 Salt spray test Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0231 | CVS40 §5.13 TC-13 Dirt spray test TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0232 | CVS40 §6.2 TM-01 Resonance search Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0233 | CVS40 §6.3 TM-02 Mechanical shock TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0234 | CVS40 §6.4 TM-03 Random vibration and thermal cycle P1 Test 2 Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0235 | CVS40 §6.5 TM-04 Gravel bombardment and impact Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0236 | CVS40 §6.6 TM-05 External forces Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0237 | CVS40 §6.7 TM-06 Drop test – Free fall Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0238 | CVS40 §7.1 TL-01 Life length As per Chapter 8 Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0239 | CVS40 §7.2.1 TL-02 Power cycling test Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0240 | CVS40 §7.2.2 TL-03 Extended thermal shock air TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0241 | CVS40 §7.2.3 TL-04 High temperature endurance test TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0242 | CVS40 §7.2.4 TL-05 Endurance test / actuation TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0243 | CVS40 §7.3 TL-06 Component specific test TBD | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0244 | CVS40 §7.4 TL-07 Ageing Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0246 | CVS40 §8.2 TS-02 UV resistance Datasheet sufficient Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0247 | CVS40 §8.3 TS-03 Chemical resistance Application method TBD Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0248 | CVS40 §8.4 TE-01 Isolation resistance and Dielectric strength tests N Exceptions and additional information to CVS41 [Y/N] | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0249 | CVS41 §4 Electrical loads Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0250 | CVS41 §4.1 TE-00 Operating Voltage Class A for ECU and communication. Class B for clutch actuation Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0251 | CVS41 §4.2 TE-01 Operating Voltage (Long-term overvoltage) Umax: 15 min, functional status Class B Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0252 | CVS41 §4.3 TE-02 Transient Overvoltage Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0253 | CVS41 §4.4 TE-03 Transient Undervoltage Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0254 | CVS41 §4.5 TE-04 Jump start Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0255 | CVS41 §4.6 TE-05 Load dump, test pulse 5b Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0257 | CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0258 | CVS46 §4.7 Test VCB CTE N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0259 | CVS46 §4.8 Test VCB AN and VCB CP N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0260 | CVS46 §4.9 Test C-VCB-VCA N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0261 | CVS46 §4.10 Test TSUP VCB A N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0262 | CVS46 §4.11 Test TSUP VCB B N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0263 | CVS46 §4.12 Test VCB Surge N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0264 | CVS46 §4.13 Test VCB Burst N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0265 | CVS46 §4.14 Test VCB Charging mode N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0266 | CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0267 | CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0268 | CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0269 | CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0270 | CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component. Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0271 | CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0272 | CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0273 | CVS46 §5.2.2 Vehicle test RE: Self interference Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0274 | CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0275 | CVS46 §5.3.1 Vehicle test: AC charging Vehicle in AC charging mode N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0276 | CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0277 | CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0278 | CVS46 §5.4.1 Vehicle test RI: External interference sources Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-3299216-1-0284 | Field test Traton will perform field tests with the unit mounted in trucks | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0004 | This document specifies the method to perform software download using Software Update Variant 2 (SUV2). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0005 | The vehicle manufacturer implementation of the Authentication service (0x29) is defined in CVS31 and SecuredDataTransmission service (0x84) is defined in CVS32. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0006 | While the requirements are applicable for programmable servers, some of the programming steps outlined in this specification (CommunicationControl and ControlDTCSetting) do not primarily target the programmable ECU, but the other ECUs on the same network which need to support the programming of the targeted ECU. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0007 | Support for programming as well as support for programming of other ECUs on the same network involves supporting what is referred to as pre- and post-programming steps. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0008 | This specification is based on ISO14229-1:2020 and as such supports a “single server” approach to non-volatile memory programming with the intention to simplify client software development without significantly complicating server software development. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0009 | With a single server objective, an ECU will appear to be programmable through communication with a single diagnostic server even if the ECU in fact implements two or more diagnostic servers – one in the boot loader and one in each application – and in reality will be programmed through communication with either one of them or both. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0010 | The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0011 | It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0012 | This specification targets ECUs, not clients. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0013 | Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0015 | The target readers of this specification are ECU suppliers, which can be either internal or external in relation to the vehicle manufacturer. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0016 | In both cases, whenever the term “ECU supplier” or just “supplier” is used in this specification it refers to the company and organization which is responsible for the implementation and delivery of the ECU according to the requirements in this specification. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0017 | The following documents are normative and indispensable for the application of this document: • ISO14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements • CVS124, Traton Specification on Unified diagnostic services (UDS) requirements • CVS154, DSC Specification • CVS31, Authenticate 0x29 • CVS36, Secure ECU Parametrization • CVS32, SecuredDataTranmission 0x84 • CVS33, Entity Management Protocol (EMP) • CVS34, Entity Management Protocol (EMP) Basic Entity Definition | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0018 | Several terms that are used in this document but not defined in Table 1 are defined by ISO or in the document CVS124. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0026 | C2 Also referred to as “programming request” flag. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0028 | C3 Also referred to as “reprogrammed” flag. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0032 | Requirements are prefixed “SUV2_REQ”. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0033 | Similarly, informative text is prefixed “SUV2_INFO”. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0038 | If as a deviation with respect to | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0045 | Boot loaders need to be updated by the vehicle manufacturer on aftermarket workshop scenarios or at a test bench during component testing, when the ECU is mounted in a vehicle during system testing or in production to fix bugs. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0054 | The “boot parameter module” permits a generic bootloader to be an ECU application platform (ECU HW + boot loader software). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0057 | For definition of DID 0xF197 see CVS124. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0060 | A joint use of program code for communication functions (com stack) by the application and the boot loader is not permitted. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0063 | It is within the scope of this specification that flash files delivered from the supplier can be encrypted by the vehicle manufacturer before storing in the vehicle manufacturer offboard database, but the server decryption of the received data will always restore it to servers memory into original data delivered by the supplier. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0065 | In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0067 | Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0073 | If a valid application is present in the ECU, some of the services described in the programming sequence will be executed in the application. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0074 | Each programming step will specify an addressing method (physical or functional), an SPRMIB (suppressPosRspMsgIndicationBit) bit value and other parameter values for the service(s) posted by the client. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0076 | The numbering of the programming sequence steps in this document generally has a well- defined relation to the numbering of the sequence steps in (ISO14229-1:2020). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0077 | Programming phase #1 is defined to program a server (e.g., download of application software, application data or boot software). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0080 | For further information on the service details and programming messages structure regarding the SecuredDataTransmission (0x84) service, refer to CVS32. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| RFQX-CVS123-2-0081 | The sequence shown in the following figure shows the Pre-Programming step of phase #1. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
| RFQX-CVS123-2-0082 | When this step is entered, the ECU is assumed to be in a state which enables it to receive UDS service requests. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Confirm if binding |
Open the requirement review register for the remaining 699 rows.