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.
Accept283Confirm responsibi
Accept with Assumption389Confirm assumption
Partially Accept275Confirm responsibi
Customer Clarification7Answer open point
Informational Only113Confirm if binding
Executive Proposal Summary
| Supplier Position | Count | Meaning | Customer Action Needed |
|---|---|---|---|
| Accept | 283 | Supplier will implement. | Confirm responsibility & method |
| Accept with Assumption | 389 | Implement under stated assumption. | Confirm assumption |
| Partially Accept | 275 | ECU part only; OEM part to confirm. | Confirm responsibility split |
| Needs Customer Clarification | 7 | Blocked pending answer. | Answer open point |
| Needs Internal Review | 9 | Supplier reviewing internally. | None yet |
| Informational Only | 113 | Context only. | Confirm if binding |
Implementation Proposal by Security Capability
| Security Capability | Related Requirements | Supplier Proposal | Customer Dependency |
|---|---|---|---|
| Authentication | 30 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Diagnostic security | 30 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Cybersecurity requirement handling | 17 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Key management | 13 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Certificate handling | 5 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Vulnerability management | 2 | Implement ECU controls; provide verification evidence | Confirm responsibility / method |
| Secure communication | 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 |
Proposals by Supplier Position
Accepted Requirements (283)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| REQ-AUTO-00004 | 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. | Confirm responsibility & method |
| REQ-AUTO-00021 | 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. | Confirm responsibility & method |
| REQ-AUTO-00028 | 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. | Confirm responsibility & method |
| REQ_SEC_0028 | Marcus Lindner EPXC Published 9(16) - 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 |
| REQ_SEC_0029 | 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 |
| REQ_SEC_0006 | 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 |
| REQ-AUTO-00047 | 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. | Confirm responsibility & method |
| REQ-AUTO-00048 | 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. | Confirm responsibility & method |
| REQ-AUTO-00052 | 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. | Confirm responsibility & method |
| REQ_SEC_0047 | Product lifecycle - 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 |
| REQ_SEC_0049 | 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 |
| REQ-AUTO-00059 | 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. | Confirm responsibility & method |
| REQ-AUTO-00060 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. | Accept. 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 |
| REQ-AUTO-00061 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. | Accept. 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 |
| REQ-AUTO-00063 | The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup. | Accept. 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 |
| REQ-AUTO-00064 | P 1 Page 2 General 2.1 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 |
| REQ-AUTO-00065 | 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling. | Accept. 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 |
| REQ-AUTO-00067 | 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. | Confirm responsibility & method |
| REQ-AUTO-00069 | 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. | Confirm responsibility & method |
| REQ-AUTO-00073 | 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. | Confirm responsibility & method |
| REQ-AUTO-00075 | 2.11 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 |
| REQ-AUTO-00079 | 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. | Accept. 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 |
| REQ-AUTO-00080 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required. | Accept. 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 |
| REQ-AUTO-00081 | 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA. | Accept. 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 |
| REQ-AUTO-00082 | 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided. | Accept. 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 |
| REQ-AUTO-00083 | 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 |
| REQ-AUTO-00085 | P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins. | Accept. 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 |
| REQ-AUTO-00086 | Figure 5 - Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep. | Accept. 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 |
| REQ-AUTO-00087 | 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. | Confirm responsibility & method |
| REQ-AUTO-00088 | 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. | Accept. 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 |
| REQ-AUTO-00090 | 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA. | Accept. 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 |
| REQ-AUTO-00096 | 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. | Confirm responsibility & method |
| req.10.5 | It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18 When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA. | Accept. 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 |
| REQ-AUTO-00100 | 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. | Confirm responsibility & method |
| REQ-AUTO-00101 | 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position. | Accept. 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 |
| REQ-AUTO-00102 | 4.23 The actuator shall apply a preload force for the release bearing. | Accept. 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 |
| REQ-AUTO-00103 | The preload force measured on the push rod shall be 150N to 250N independent of the clutch position 4.24 The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP). | Accept. 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 |
| REQ-AUTO-00104 | 4.25 It must be possible to assemble the actuator independent of the lever position without any power 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. | Confirm responsibility & method |
| REQ-AUTO-00105 | 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. | Confirm responsibility & method |
| REQ-AUTO-00106 | 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req. | Accept. 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 |
| REQ-AUTO-00108 | 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. | Confirm responsibility & method |
| req-6.4 | P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see req 6.4). | Accept. 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 |
| REQ-AUTO-00110 | 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. | Confirm responsibility & method |
| REQ-AUTO-00111 | P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). | Accept. 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 |
| REQ-AUTO-00112 | 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req. | Accept. 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 |
| REQ-AUTO-00113 | 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) 5.6 The actuator must be able to determine the pushrod position according to the following: Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm. | Accept. 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 |
| REQ-AUTO-00114 | Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch. | Accept. 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 |
| REQ-AUTO-00115 | This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req. | Accept. 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 |
| REQ-AUTO-00117 | 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. | Accept. 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 |
| REQ-AUTO-00118 | P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s. | Accept. 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 |
| REQ-AUTO-00119 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. | Accept. 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 |
| REQ-AUTO-00120 | 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent. | Accept. 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 |
| REQ-AUTO-00121 | 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. | Confirm responsibility & method |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.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 |
| REQ-AUTO-00124 | 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. | Confirm responsibility & method |
| REQ-AUTO-00125 | 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. | Confirm responsibility & method |
| req-8.1 | The test shall be done with the highest operating temperature (see req 8.1) and maximum clutch force (See Appendix A) Figure 11 - Release frequency 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. | Confirm responsibility & method |
| REQ-AUTO-00127 | Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. | Accept. 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 |
| REQ-AUTO-00128 | 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. | Confirm responsibility & method |
| REQ-AUTO-00129 | 5.1 and 5.2) Figure 12 - Class B exceptions 5.14 It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min. | Accept. 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 |
| REQ-AUTO-00130 | 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. | Confirm responsibility & method |
| REQ-AUTO-00131 | 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. | Confirm responsibility & method |
| REQ-AUTO-00132 | 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. | Confirm responsibility & method |
| REQ-AUTO-00133 | 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. | Confirm responsibility & method |
| REQ-AUTO-00134 | 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. | Confirm responsibility & method |
| REQ-AUTO-00135 | Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP). | Accept. 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 |
| REQ-AUTO-00136 | 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. | Confirm responsibility & method |
| REQ-AUTO-00137 | 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. | Confirm responsibility & method |
| REQ-AUTO-00144 | 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. | Confirm responsibility & method |
| REQ-AUTO-00147 | 6.11 SW number: The ECA shall report a complete SW version 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 |
| REQ-AUTO-00148 | 6.12 HW number: The ECA shall report a complete HW version 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 |
| REQ-AUTO-00151 | 6.14 System state The ECA shall report its current System State. | Accept. 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 |
| REQ-AUTO-00153 | 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position 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. | Confirm responsibility & method |
| REQ-AUTO-00154 | 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position 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. | Confirm responsibility & method |
| REQ-AUTO-00155 | 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque 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. | Confirm responsibility & method |
| REQ-AUTO-00156 | 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e. | Accept. 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 |
| REQ-AUTO-00157 | 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation routine and is not yet available for control. | Accept. 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 |
| REQ-AUTO-00158 | 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control. | Accept. 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 |
| REQ-AUTO-00160 | 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation. | Accept. 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 |
| REQ-AUTO-00161 | P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14.14) 6.16 Torque Feedback The ECA shall calculate and report the actuator motor torque. | Accept. 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 |
| REQ-AUTO-00162 | (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator. | Accept. 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 |
| REQ-AUTO-00163 | 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. | Confirm responsibility & method |
| REQ-AUTO-00165 | (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage. | Accept. 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 |
| Req.ID-Description-6.19.1 | (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed important to store (req.6.16.1, req 6.16.2) (Ref 14.14) Req.ID Description 6.19.1 Operational hours: The ECA shall store and report its accumulated operational hours. | Accept. 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 |
| REQ-AUTO-00167 | 6.19.2 Total travelled length: 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 |
| REQ-AUTO-00179 | 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants. | Accept. 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 |
| REQ-AUTO-00181 | ID General electrical requirements 7.1 The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot- through”) is avoided. | Accept. 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 |
| REQ-AUTO-00182 | 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. | Confirm responsibility & method |
| REQ-AUTO-00184 | 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss. | Accept. 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 |
| Req.ID-Connector-Requirements-7.5 | Req.ID Connector Requirements 7.5 All external electrical connectors shall 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 |
| REQ-AUTO-00186 | 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 |
| REQ-AUTO-00187 | 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e. | Accept. 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 |
| REQ-AUTO-00188 | 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. | Confirm responsibility & method |
| REQ-AUTO-00189 | 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. | Confirm responsibility & method |
| REQ-AUTO-00191 | 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. | Confirm responsibility & method |
| REQ-AUTO-00192 | 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. | Confirm responsibility & method |
| REQ-AUTO-00197 | Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d. | Accept. 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 |
| REQ-AUTO-00198 | 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. | Confirm responsibility & method |
| REQ-AUTO-00205 | 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. | Confirm responsibility & method |
| REQ-AUTO-00207 | 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. | Confirm responsibility & method |
| REQ-AUTO-00208 | 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. | Confirm responsibility & method |
| REQ-AUTO-00210 | 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. | Confirm responsibility & method |
| REQ-AUTO-00211 | 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. | Confirm responsibility & method |
| REQ-AUTO-00213 | 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. | Confirm responsibility & method |
| REQ-AUTO-00214 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. | Accept. 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 |
| REQ-AUTO-00215 | HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610. | Accept. 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 |
| REQ-AUTO-00216 | 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. | Confirm responsibility & method |
| REQ-AUTO-00217 | 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane. | Accept. 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 |
| REQ-AUTO-00219 | 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. | Confirm responsibility & method |
| REQ-AUTO-00221 | 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. | Confirm responsibility & method |
| REQ-AUTO-00222 | 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. | Confirm responsibility & method |
| REQ-AUTO-00223 | 8.3 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 |
| REQ-AUTO-00226 | 8.5 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 |
| REQ-AUTO-00227 | 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable. | Accept. 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 |
| REQ-AUTO-00228 | 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. | Confirm responsibility & method |
| REQ-AUTO-00229 | 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 |
| REQ-AUTO-00230 | 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing. | Accept. 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 |
| REQ-AUTO-00231 | ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868. | Accept. 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 |
| REQ-AUTO-00233 | 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. | Confirm responsibility & method |
| REQ-AUTO-00234 | 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. | Confirm responsibility & method |
Open the requirement review register for the remaining 163 rows.
Accepted with Assumptions (389)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. | 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 |
| REQ_SEC_0001 | Cybersecurity methods and strategies - 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. | Confirm assumption |
| REQ_SEC_0002 | Risk assessment - 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. | Confirm assumption |
| REQ-AUTO-00005 | 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. | Confirm assumption |
| REQ_SEC_0003 | Cybersecurity concept - 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 |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16) - 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 |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. | 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 |
| REQ_SEC_0023 | 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 |
| REQ-AUTO-00011 | 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. | Confirm assumption |
| REQ_SEC_0024 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. | 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 |
| REQ_SEC_0004 | Verification and validation - 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 |
| REQ_SEC_0005 | 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 |
| REQ_SEC_0007 | Documentation - 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 |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16) - A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ_SEC_0042 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. | 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 |
| REQ_SEC_0008 | Software security - 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 |
| REQ_SEC_0009 | Security architecture - 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 |
| REQ_SEC_0020 | Cryptographic libraries - 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 |
| REQ_SEC_0010 | Services - 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 |
| REQ_SEC_0011 | 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 |
| REQ_SEC_0012 | Interfaces - 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 |
| REQ_SEC_0013 | 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 |
| REQ_SEC_0014 | 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 |
| REQ-AUTO-00030 | 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. | Confirm assumption |
| REQ_SEC_0027 | Information security - 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 |
| REQ_SEC_0019 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ_SEC_0021 | 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 |
| REQ_SEC_0015 | 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 |
| REQ_SEC_0043 | Security updates - 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 |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16) - 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 |
| REQ_SEC_0044 | Incident management - 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 |
| REQ_SEC_0045 | 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 |
| REQ_SEC_0046 | 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 |
| REQ_SEC_0032 | 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 |
| REQ_SEC_0033 | Vulnerability management - 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 |
| REQ_SEC_0035 | Marcus Lindner EPXC Published 11(16) - Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability. | 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 |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability. | 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 |
| REQ_SEC_0036 | 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 |
| REQ_SEC_0037 | 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 |
| REQ_SEC_0048 | 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 |
| REQ_SEC_0051 | Logging - 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 |
| REQ-AUTO-00066 | 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection 2.6 The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17). | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00068 | Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00070 | The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00071 | 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00072 | Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox 2.8 The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components. | 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 |
| REQ-AUTO-00074 | 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. | Confirm assumption |
| REQ-AUTO-00076 | 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. | Confirm assumption |
| REQ-AUTO-00084 | 4.8 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 |
| REQ-AUTO-00089 | Surface indents in the contacts are allowed as long as the structural integrity is unaffected 4.12 The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00092 | 4.14 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 |
| REQ-AUTO-00093 | 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00094 | 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 - ISO view of 3D envelope. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00095 | P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00098 | Figure 6 - Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00099 | The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox 4.20 The connector for communication and power shall be positioned as indicated in Figure 4 - ISO view of 3D envelope, when connected. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00116 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00138 | ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00139 | 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. | Confirm assumption |
| REQ-AUTO-00141 | 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. | Confirm assumption |
| REQ-AUTO-00143 | 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. | Confirm assumption |
| REQ-AUTO-00145 | 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| req-6.20 | 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req. | 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 |
| REQ-AUTO-00150 | 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. | Confirm assumption |
| REQ-AUTO-00152 | 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. | Confirm assumption |
| REQ-AUTO-00159 | 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00164 | 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. | Confirm assumption |
| REQ-AUTO-00168 | 6.20 Diagnosis: 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 |
| REQ-AUTO-00169 | 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00172 | P 1 Page 6.23 Validation and Invalidation: 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 |
| REQ-AUTO-00173 | 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc. | 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 |
| REQ-AUTO-00174 | If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00176 | 6.25 Data logging: 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 |
| REQ-AUTO-00177 | 6.26 Data storage: When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00178 | The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00180 | 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00183 | 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00193 | 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. | Confirm assumption |
| REQ-AUTO-00194 | 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. | Confirm assumption |
| REQ-AUTO-00195 | After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00196 | After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00199 | 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. | Confirm assumption |
| REQ-AUTO-00200 | 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. | Confirm assumption |
| REQ-AUTO-00201 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00202 | 7.35 The controller and transceiver shall be CAN FD ready. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00203 | 7.36 Termination resistance: - 2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00204 | ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00206 | 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. | Confirm assumption |
| REQ-AUTO-00209 | 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. | Confirm assumption |
| REQ-AUTO-00212 | The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00218 | The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00220 | The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00224 | 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. | Confirm assumption |
| REQ-AUTO-00225 | 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. | Confirm assumption |
| REQ-AUTO-00232 | Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00239 | 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. | Confirm assumption |
| REQ-AUTO-00241 | 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. | Confirm assumption |
| REQ-AUTO-00253 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00256 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00257 | This test must verify that all internal and external I/O fulfils the requirements in this specification. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00258 | A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Product Validation at C-sample level) environmental test programs according to CVS40 and CVS41 (incl. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00260 | Additional tests initiated and performed by the supplier must be discussed 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 |
| REQ-AUTO-00261 | A3 The supplier must test the connectors according to TB1787. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00262 | A4 The supplier must do EMC tests with the unit alone. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00263 | The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00264 | A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00266 | 12.3 Testability The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00267 | However, dividing sample phases into several generations must be agreed upon between Traton 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 |
| REQ-AUTO-00271 | The supplier must use the sample denominations requested by Traton. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00273 | P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500000 repetitions of the test cycle described in ”I – Test cycle” Two different test profiles/setups can be used. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00277 | • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C as well as the release frequency test is performed, before the rigs are put into run-to-failure mode • Run-to-failure mode implies cycling at intermediate load and RT/80C until failure • @Temp durability will start with 15/min frequency to verify if 30/min is feasible • One rig at RT shall run at 15/min as a reference unit for cycle acceleration. | 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 |
| REQ-AUTO-00290 | All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating system, start-up code, low level flash routines (for erasing, writing, reading), EEPROM access routines (read, write functionality), software compatibility checks etc. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00291 | shall be implemented in the boot software code. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm assumption |
| REQ-AUTO-00297 | Satisfied programming precondition A programming precondition agreed between supplier and vehicle manufacturer which, together with other agreed programming preconditions, shall be fulfilled before an ECU is made eligible for programming. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00300 | Requirements in (CVS124) which are not explicitly stated to apply to the application only (such as communication parameters) shall apply to the boot loader as well. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00302 | SUV2_REQ 3 The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00303 | SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00307 | SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00308 | SUV2_REQ 7 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 |
| REQ-AUTO-00311 | Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer. | Accept with assumption. Implement ECU-side 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 |
Open the requirement review register for the remaining 269 rows.
Partially Accepted Requirements (275)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| REQ_SEC_0026 | 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 |
| REQ_SEC_0016 | Key management - 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 |
| REQ_SEC_0034 | 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 |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16) - All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00078 | P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00091 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| req-5.10 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00140 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00247 | P 1 Page 10.5.11 CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y 10.5.12 CVS40 §5.6 TC-06 Thermal shock Y 10.5.13 CVS40 §5.7 TC-07 Splash water test Y 10.5.14 CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y 10.5.15 CVS40 §5.9 TC-09 Leakage search test Y 10.5.16 CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00282 | SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU. | Partially accept. ECU-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 |
| REQ-AUTO-00299 | Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification. | Partially accept. ECU-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 |
| REQ-AUTO-00306 | SUV2_REQ 5 The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests. | Partially accept. ECU-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 |
| REQ-AUTO-00309 | SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded. | Partially accept. ECU-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 |
| REQ-AUTO-00310 | SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification. | Partially accept. ECU-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 |
| REQ-AUTO-00313 | SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data). | Partially accept. ECU-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 |
| REQ-AUTO-00321 | 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. | Partially accept. ECU-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 |
| REQ-AUTO-00329 | Page 12 5 Detailed programming sequence SUV2_REQ 23 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 |
| REQ-AUTO-00330 | SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). | Partially accept. ECU-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 |
| REQ-AUTO-00332 | The full set of addressing modes, SPRMIB values and other parameter values that the server shall support for each service are specified with implementation requirements in CVS124. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00333 | SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service. | Partially accept. ECU-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 |
| REQ-AUTO-00334 | SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled. | Partially accept. ECU-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 |
| REQ-AUTO-00336 | SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requires update and perform the appropriate set to update the entities stored in the server. | Partially accept. ECU-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 |
| REQ-AUTO-00339 | SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory). | Partially accept. ECU-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 |
| REQ-AUTO-00340 | SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. | Partially accept. ECU-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 |
| REQ-AUTO-00341 | SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory. | Partially accept. ECU-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 |
| REQ-AUTO-00345 | If so, the server performs the required checks/reorganization measures for the data structures (EEPROM data, operational data, adaptive data etc.), executes the self-test and stores event memory entries, default values, DIDs F1AB, F1AA, F1A9 etc. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00347 | SUV2_INFO 85 As example, the client may have identified that the new software requires an updated RBAC configuration file and therefore set the entity on the server via EMP. | Partially accept. ECU-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 |
| REQ-AUTO-00348 | Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programming SUV2_REQ 33 ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. | Partially accept. ECU-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 |
| REQ-AUTO-00350 | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot. | Partially accept. ECU-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 |
| REQ-AUTO-00353 | SUV2_REQ 38 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 |
| REQ-AUTO-00366 | SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence. | Partially accept. ECU-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 |
| REQ-AUTO-00367 | 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements SUV2_REQ 50 The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. | Partially accept. ECU-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 |
| REQ-AUTO-00373 | 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). | Partially accept. ECU-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 |
| REQ-AUTO-00375 | SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). | Partially accept. ECU-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 |
| REQ-AUTO-00377 | 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. | Partially accept. ECU-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 |
| REQ-AUTO-00379 | SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | Partially accept. ECU-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 |
| REQ-AUTO-00381 | SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 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 |
| REQ-AUTO-00383 | SUV2_REQ 69 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 |
| REQ-AUTO-00385 | SUV2_REQ 190 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. | Confirm responsibility split |
| REQ-AUTO-00386 | 7.1.1 Request SUV2_REQ 72 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. | Confirm responsibility split |
| REQ-AUTO-00387 | Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6. | Partially accept. ECU-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 |
| REQ-AUTO-00388 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response SUV2_REQ 74 The server shall support service negative response as per ISO14229-1:2020. | Partially accept. ECU-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 |
| REQ-AUTO-00389 | 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. | Partially accept. ECU-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 |
| REQ-AUTO-00390 | SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. | Partially accept. ECU-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 |
| REQ-AUTO-00391 | SUV2_REQ 167 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. | Confirm responsibility split |
| REQ-AUTO-00394 | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier SUV2_REQ 77 The server shall support parameter lengthFormatIdentifier formatted according to Table 9. | Partially accept. ECU-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 |
| REQ-AUTO-00395 | M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support request formatted according to ISO14229-1:2020. | Partially accept. ECU-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 |
| REQ-AUTO-00398 | 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. | Partially accept. ECU-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 |
| REQ-AUTO-00400 | 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10. | Partially accept. ECU-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 |
| REQ-AUTO-00401 | Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response SUV2_REQ 85 The server shall support positive response formatted according to Table 11. | Partially accept. ECU-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 |
| REQ-AUTO-00402 | Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestTransferExit Response SID M 0x77 7.3.3 Negative Response SUV2_REQ 86 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord SUV2_REQ 87 The server shall not support transferRequestParameterRecord parameter. | Partially accept. ECU-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 |
| REQ-AUTO-00404 | 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 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. | Confirm responsibility split |
| REQ-AUTO-00408 | 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. | Partially accept. ECU-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 |
| REQ-AUTO-00409 | 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. | Partially accept. ECU-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 |
| REQ-AUTO-00411 | 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support SUV2_REQ 97 The server shall support the routine in the diagnosticSession according to Table 12. | Partially accept. ECU-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 |
| REQ-AUTO-00412 | Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support SUV2_REQ 98 The server shall support the routineControlType according to Table 13. | Partially accept. ECU-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 |
| REQ-AUTO-00413 | Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement SUV2_REQ 181 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. | Partially accept. ECU-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 |
| REQ-AUTO-00414 | SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum. | Partially accept. ECU-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 |
| REQ-AUTO-00419 | SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. | Partially accept. ECU-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 |
| REQ-AUTO-00422 | SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | Partially accept. ECU-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 |
| REQ-AUTO-00429 | Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Application Data 0x04 – 0xFF System Specific 8.3.4.2 Paramter routineStatus routineResult SUV2_REQ 115 The server shall support parameter routineStatus routineResult formatted according to Table 22. | Partially accept. ECU-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 |
| REQ-AUTO-00435 | SUV2_REQ 119 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. | Confirm responsibility split |
| REQ-AUTO-00436 | SUV2_REQ 120 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. | Confirm responsibility split |
| REQ-AUTO-00437 | SUV2_REQ 121 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. | Confirm responsibility split |
| REQ-AUTO-00440 | Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF #6 … #7 routineResultProofLength M Uint16 #8 … #n routineResultProof M Uint8[] 8.4.3 Negative Response SUV2_REQ 124 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult SUV2_REQ 125 The server shall support parameter routineStatus routineResult formatted according to Table 25. | Partially accept. ECU-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 |
| REQ-AUTO-00441 | Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M SUV2_REQ 126 The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. | Partially accept. ECU-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 |
| REQ-AUTO-00442 | If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24 the following diagnostic services and routines until a new SDSC is provided: | 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 |
| REQ-AUTO-00445 | SUV2_REQ 173 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. | Confirm responsibility split |
| REQ-AUTO-00446 | SUV2_REQ 174 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 |
| REQ-AUTO-00448 | Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification SUV2_REQ 183 The client shall send the Servers routineStatus routineResult response to the backend. | Partially accept. ECU-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 |
| REQ-AUTO-00450 | Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: SUV2_REQ 177 • Routine 0xFF00 Erase Memory SUV2_REQ 178 • Service 0x34 RequestDownload SUV2_REQ 179 • Service 0x36 TransferData SUV2_REQ 180 • Service 0x37 RequestTransferExit | Partially accept. ECU-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 |
| REQ-AUTO-00452 | Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response SUV2_REQ 130 The server shall support the routine positive response according to Table 27. | Partially accept. ECU-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 |
| REQ-AUTO-00453 | #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall support the routine negative response according to CVS33. | Partially accept. ECU-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 |
| REQ-AUTO-00454 | 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall support the parameter EMP message according to CVS33. | Partially accept. ECU-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 |
| REQ-AUTO-00455 | Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information required for the server for verifying software integrity and optionally decrypt the transported data from a trusted source, is described in a Software Data Security Container (SDSC). | Partially accept. ECU-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 |
| REQ-AUTO-00464 | 9.2 Software Verification SUV2_REQ 152 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 |
| REQ-AUTO-00470 | Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased. | Partially accept. ECU-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 |
| REQ-AUTO-00471 | SUV2_REQ 158 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. | Confirm responsibility split |
| REQ-AUTO-00473 | SUV2_REQ 160 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 |
| REQ-AUTO-00474 | SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted. | Partially accept. ECU-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 |
| REQ-AUTO-00482 | S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB When ECU recieves data that matches an address range in an EncryptionEntry (here in Module B), the server must decrypt the data received by TransferData request. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ-AUTO-00483 | Module B is encrypted meaning that when the server receives data within a range (given as address and size in RequestDownload) the server must decrypt the data before storing it. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm responsibility split |
| REQ_UDS-0001 | Internal Page 8 (90) 5 Requirements 5.1 General Requirements - The implementation of the client and the server shall be compliant with ISO 14229-1 with the clarifications, extensions and exceptions stated in this specification. | 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 |
| REQ_UDS-0047 | 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. | Confirm responsibility split |
| REQ_UDS-0338 | Internal Page 27 (90) Figure 2 -State Diagram - The session transitions stated below shall be possible to request both physically or functionally addressed to the server, otherwise the applicable addressing method is stated for the explicit transition. | 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 |
| REQ-AUTO-00561 | In this process, it shall end all routines and functions that influence programming and ensure that the server checked for safe state conditions at minimal. | Partially accept. ECU-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 |
| REQ_UDS-0060 | Before switching to programming session, the server shall ensure the applicable conditions as per Table 76 - Programming preconditions is checked to ensure the vehicle is in safe condition. | Partially accept. ECU-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 |
| REQ_UDS-0063 | ECU shall execute the reset only after sending a positive response to the ECU reset service REQ_UDS 0064 After a final positive response has been sent for ECUReset the server is not allowed to respond to any diagnostic service requests (except ECU identification) until it has restarted and been re- initialized. | 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 |
| REQ_UDS-0065 | 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 |
| REQ_UDS-0067 | The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented. | 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 |
| REQ_UDS-0068 | Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetType - Table 44 – Service 0x11 request parameter resetType description Hex (bit 6-0) Description Cvt 0x01 hardReset M 0x02 keyOffOnReset C C = If the server is connected to the ignition key REQ_UDS 0069 The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e. | 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 |
| REQ_UDS-0071 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response. | 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 |
| REQ-AUTO-00578 | INFO_UDS 0010 The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType. | 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 |
| REQ_UDS-0075 | 5.5.3 CommunicationControl (0x28) service - 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. | Confirm responsibility split |
| REQ_UDS-0076 | INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacks - When receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses REQ_UDS 0077 Safety conditions are project specific and shall be checked before accepting a request to disable communication. | 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 |
| REQ_UDS-0250 | 5.5.4.3 Positive response - 5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDTCSetting (0x85) service REQ_UDS 0343 Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied. | Partially accept. ECU-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 |
| REQ_UDS-0082 | 5.5.6 Link Control (0x87) service - 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 |
| REQ_UDS-0083 | The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application. | Partially accept. ECU-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 |
| REQ_UDS-0089 | 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteDataByIdentifier (0x2E) service - The sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order REQ_UDS 0090 The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant. | 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 |
| REQ-AUTO-00636 | Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m #35..#38 Total vehicle distance at the latest DTC activation [4-byte int, big endian] in section 5.7.4.1 Not used for TRATON External engine and marine ECUsFor these ECUs these bytes shall contain default value 0xFF (all bytes). | 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 |
| REQ_UDS-0108 | 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Request Download Service (0x34) - If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. | 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 |
| REQ_UDS-0109 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | 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 |
| REQ_UDS-0111 | Internal Page 58 (90) - If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub- functionNotSupported) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. | Partially accept. ECU-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 |
| REQ_UDS-0112 | 5.5.13.1 Request - 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. | Confirm responsibility split |
| REQ_UDS-0128 | 5.5.17.3 Negative response - Negative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes REQ_UDS 0129 Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service REQ_UDS 0130 Authentication (0x29) service shall be used for authentication of client and server. | 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 |
| REQ-AUTO-00691 | Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions. | 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 |
| REQ_UDS-0158 | The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. | 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 |
| REQ_UDS-0160 | Internal Page 70 (90) - When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). | 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 |
| REQ_UDS-0170 | 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. | Confirm responsibility split |
| REQ_UDS-0171 | 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. | Confirm responsibility split |
| REQ_UDS-0172 | If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed). | 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 |
| REQ-AUTO-00733 | 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 0029 This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence. | Partially accept. ECU-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 |
| REQ_UDS-0183 | Internal Page 77 (90) - The server shall check whether or not the individual modules are complete and compatible with one another. | 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 |
| REQ_UDS-0185 | 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. | Confirm responsibility split |
| REQ_UDS-0186 | 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. | Confirm responsibility split |
| REQ_UDS-0187 | 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. | Confirm responsibility split |
| REQ_UDS-0188 | 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. | Confirm responsibility split |
| REQ_UDS-0190 | 5.6.4.1 Request - 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. | Confirm responsibility split |
| REQ_UDS-0194 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP The request and response shall be implemented according to CVS33. | Partially accept. ECU-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 |
| REQ_UDS-0202 | 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 |
Open the requirement review register for the remaining 155 rows.
Rejected Requirements (0)
None.
Clarification Needed (7)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Answer open point |
| REQ-AUTO-00146 | Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN. | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Answer open point |
| REQ-AUTO-00317 | It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform. | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00488 | 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification. | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Answer open point |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). | Accept with assumption. Implement ECU-side 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 |
| REQ-AUTO-00634 | Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2. | 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 |
| REQ-AUTO-00866 | 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ DSC_BASE_REQ 42 The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp } | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Answer open point |
Customer-Owned / Informational (113)
| Requirement ID | Requirement | Proposal | Customer Action |
|---|---|---|---|
| REQ_SEC_0040 | 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 |
| REQ_SEC_0041 | The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| req-6.3 | The signal is valid during Control Modes RPC and TC(see req 6.3). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| Req.ID-Description-6.22.1 | Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the phases 6.22.3 Motor rotation feedback, short circuit / open load | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00171 | P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6.22.6 Low voltage 30 6.22.7 CAN-timeout (stored and sent when possible) 6.22.8 High temperature/current consumption (system needs to indicate abnormal usage that can damage the device), indicate a self-protective mode (if applicable) 6.22.9 Error on temperature sensor 6.22.10 High friction in mechanical system 6.22.11 Other electrical HW error | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00175 | 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 |
| REQ-AUTO-00190 | 7.17 Umax: - - 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00246 | 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 |
| REQ-AUTO-00249 | P 1 Page 10.7.14 CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y 10.7.15 CVS46 §4.7 Test VCB CTE N 10.7.16 CVS46 §4.8 Test VCB AN and VCB CP N 10.7.17 CVS46 §4.9 Test C-VCB-VCA N 10.7.18 CVS46 §4.10 Test TSUP VCB A N 10.7.19 CVS46 §4.11 Test TSUP VCB B N 10.7.20 CVS46 §4.12 Test VCB Surge N 10.7.21 CVS46 §4.13 Test VCB Burst N 10.7.22 CVS46 §4.14 Test VCB Charging mode N 10.7.23 CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y 10.7.24 CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y 10.7.25 CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y 10.7.26 CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y 10.7.27 CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00250 | Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29 CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y 10.7.30 CVS46 §5.2.2 Vehicle test RE: Self- interference Y 10.7.31 CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N 10.7.32 CVS46 §5.3.1 Vehicle test: AC charging: Vehicle in AC charging mode N 10.7.33 CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N 10.7.34 CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y 10.7.35 CVS46 §5.4.1 Vehicle test RI: External interference sources Y | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00272 | Unless otherwise stated, valid version is the latest available as of 1st May 2026. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00278 | This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00279 | TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“CVS123-2”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00284 | 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 |
| REQ-AUTO-00292 | The value of this variable (and C2, see below) may be used by the boot manager to determine whether to start the application or the boot loader. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00294 | The value of this variable (and C1, see above) may be used by the boot manager to determine whether or not to start the application or the boot loader. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00298 | Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memory | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00335 | SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configuration file to verify if the appropriate entities are stored in the server. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00337 | Alternatively, it may be a client strategy to always update certain entities prior to a software update. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00338 | SUV2_INFO 52 Since Link Control is only applicable in production when no application has been programmed by the supplier, the application may return NRC 0x7F (serviceNotSupportedInActiveSession) to this service request and expect the client to proceed to the next step. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00343 | SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not programmed, regardless of this the server verifies the integrity according to the supplied information on SDSC, see 9. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00378 | SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00420 | SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00480 | SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will be based on the range defined. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00485 | Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00492 | May This word, or the adjective “Optional”, means that an item is truly optional. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0003 | Modified requirements - Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0004 | Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifier - Table 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x01 #2 : #14 Boot software identifier #1: : M : M 0x7E . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0006 | 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifier - Table 7 – Description of DID 0xF181 applicationSoftwareIdentificationDataIdentifier 0xF181 Name : applicationSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application software identifier #1: : M 0x7E 0x7E 0x20 : : : #n – 12 : #n Application software identifier #m: : C 0x7E 0x7E 0x20 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0007 | Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifier - Table 8 – Description of DID 0xF182 applicationDataIdentificationDataIdentifier 0xF182 Name: applicationDataIdentificationDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application data module part number #1: : 13 Bytes- M : M 0x7E . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0008 | 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifier - Table 9 – Description of DID 0xF186 ActiveDiagnosticSessionDataIdentifier 0xF186 Name: ActiveDiagnosticSessionDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 Diagnostic session type 1-Byte-A_UINT32 M 0x00 – 0xFF 0x01 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0010 | 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier - Table 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 REQ_UDS 0234 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier REQ_UDS 0011 Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte Data | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0014 | Internal Page 14 (90) byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 0x20, 0x30 – 0x39 5.2.1.10 DID 0xF18C ECUSerialNumberDataIdentifier Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data To be specified by the supplier. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0015 | 5.2.1.11 DID 0xF190 VINDataIdentifier - Table 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0016 | 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier - Table 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte Data | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0017 | 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier - Table 18 – Description of DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier 0xF192 Name: systemSupplierECUHardwareNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.14 DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier REQ_UDS 0018 Table 19 – Description of DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier 0xF193 Name: systemSupplierECUHardwareVersionNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.15 DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier REQ_UDS 0019 Table 20 – Description of DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier 0xF194 Name: systemSupplierECUSoftwareNumberDataIdentifier Byte No Description Format Cvt Byte Value Data To be specified by the External Supplier | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0020 | Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier - Table 21 – Description of DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier 0xF195 Name: systemSupplierECUSoftwareVersionNumberDataIdentifier Byte Data To be specified by the External supplier 5.2.1.17 DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier REQ_UDS 0021 Table 22 – Description of DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier 0xF196 Name: exhaustRegulationOrTypeApprovalNumberDataIdentifier Cvt: E Byte Data #1 : #10 Exhaust regulation or type approval 10-Bytes- M : M : 0000000 000 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier REQ_UDS 0022 Table 23 – Description of DID 0xF197 systemNameOrEngineTypeDataIdentifier 0xF197 Name: systemNameOrEngineTypeDataIdentifier Byte Data #1 : #22 System name or engine type 6-to-22-Bytes- G, M : C : 0x20 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0340 | 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiers - Table 25 – Description of DID 0xF199 SoftwareAssemblySemanticDataIdentifier s 0xF199 Name: SoftwareAssemblySemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0341 | 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiers - Table 26 – Description of DID 0xF19A HardwareSemanticDataIdentifiers 0xF19A Name: HardwareSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 #4 : #n+3 HardwareSemantic Data Identifier #1: : byte #n* A_ASCIISTR ING, zero M 0x00, 0x20 – 0x7E : : : : : : : HardwareSemantic Data Identifier #m: : byte #q* A_ASCIISTR ING, zero C 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0023 | Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifier - Table 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data #1 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0025 | #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 8-Bytes- RING M : M : 0x2020 20202 020 5.2.1.23 DID 0xF1A5 vehicleManufacturerECUHardwareWithoutBootNumber Table 28 – Description of DID 0xF1A5 vehicleMannufacturerECUHardwareWithoutBootNumber 0xF1A5 Name: vehicleManufacturerECUHardwareWithoutBootNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufactur er ECU Hardware Number Byte #2 : 13-Byte- M : M : Project 5.2.1.24 DID 0xF1A6 engineNumber REQ_UDS 0026 Table 29 – Description of DID 0xF1A6 engineNumber 0xF1A6 Name: engineNumber Byte Data #1 : #14 Engine number 14-Bytes- A_ASCIISTRING MM : 0x20 C = Applicable only for TRATON standalone engine solutions | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0030 | Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Description 0xF1AA Name: mileageAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Mileage at software update stamp Unit: km Formula: 0,005*X 4-Bytes- A_UINT32 M : M : 0xFFFFFFFF C = Mandatory for ECUs that store Operational data and have access to Vehicle milage information. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0032 | Internal Page 21 (90) - Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0033 | 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifier - Table 33 – Description of DID 0xF1AD activeECUSoftwareDataIdentifier 0xF1AD Name: activeECUSoftwareDataIdentifier Byte Data #1 : #2 Active ECU Software 2-Bytes- A_BYTEFIEL D M : M Boot loader: 0x0000 Application Software: 0x0002 No information: 0xFFFF Not applicabl e 5.2.1.29 DID 0xF1AF NodeUID REQ_UDS 0034 Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0036 | 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumber - Table 35 – Description of DID 0xF1B9 RBACCIdentifierNumber 0xF1B9 Name: RBACCIdentifierNumber Byte Data #1 : #16 RBACC Identifier Number 16-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0006 Information on RBACC can be found in CVS151. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0037 | 5.2.1.31 DID 0xF1BA RBACCStructureVersion - Table 36 – Description of DID 0xF1BA RBACCStructureVersion 0xF1BA Name: RBACCStructureVersion Byte Data #1 : #2 RBACC Structure Version 2-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0007 Information on RBACC can be found in CVS151. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0038 | 5.2.1.32 DID 0xF1D1 RootCertificateIdentifier - Table 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte Data | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0041 | The default diagnostic session is referred to as “defaultSession”. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0045 | Internal Page 24 (90) - Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader Def Def Extd Prg Extd DiagnosticSessionControl (0x10) F, P M M M M M ECUReset (0x11) F, P M M M M M SecurityAccess (0x27) - - - - - CommunicationControl (0x28) F, P - M - - M TesterPresent (0x3E) F, P M M M M M AccessTimingParameter (0x83) - - - - - Authentication (0x29) F, P M M M M M SecuredDataTransmission (0x84) P M M M M M ControlDTCSetting (0x85) F, P - M - - M LinkControl (0x87) - C - C C ReadDataByIdentifier (0x22) F, P M M M M M ReadMemoryByAddress (0x23) - - - - - ReadScalingDataByIdentifier (0x24) - - - - - ReadDataByPeriodicIdentifier (0x2A) - - - - - DynamicallyDefineDataIdentifier (0x2C) P U U - - - WriteDataByIdentifier (0x2E) P - M - M C WriteMemoryByAddress (0x3D) - - - - - ClearDiagnosticInformation (0x14) F, P M M - - - ReadDTCInformation (0x19) F, P M M - - - InputOutputControlByIdentifier (0x2F) P - C - - - RoutineControl (0x31) P M M - M M RequestDownload (0x34) P - C - C1 C1 RequestUpload (0x35) P - C - - - TransferData (0x36) P - C - M C RequestTransferExit (0x37) P - C - M C RequestFileTransfer (0x38) P - C - C1 C1 C1 = Either 0x34 or 0x38 is mandatory depending on file based or memory based ECU system. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0049 | Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0305 | INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained from - to REQ_UDS 0337. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0306 | Internal Page 28 (90) - 2. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0316 | Internal Page 29 (90) - 12. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0328 | Internal Page 30 (90) - 24. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00563 | Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0073 | 5.5.2.2 Positive response - Table 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType M | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0074 | 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codes - Table 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0078 | 5.5.3.1 Request - Table 47 – Service 0x28 request parameter description 1 CommunicationControl Request SID M 2 controlType M 3 communicationType M 5.5.3.1.1 Request parameter controlType REQ_UDS 0079 Table 48 – Service 0x28 request parameter controlType description Hex (bit 6-0) Description Cvt 0x00 enableRxAndTx M 0x01 enableRxAndDisableTx M 0x40 – 0x5F vehicleManufacturerSpecific U 5.5.3.1.2 Request parameter communicationType REQ_UDS 0080 Table 49 – Service 0x28 request parameter communicationType description Bits Value (Hex) Description Cvt 0 -1 1 normalCommunicationMessages M 4 – 7 0 Disable / Enable specified communicationType M 5.5.3.2 Positive response REQ_UDS 0247 5.5.3.3 Negative response REQ_UDS 0248 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00588 | INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0345 | 5.5.5.1 Request - Refer to ISO 14229-1 for request format. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0346 | 5.5.5.1.1 Request parameter DTCSettingType - Refer to ISO 14229-1 for request parameter DTCSettingType. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0347 | Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord - Refer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0348 | 5.5.5.2 Positive response - Refer to ISO 14229-1 for positive response format and parameter. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0349 | 5.5.5.3 Negative response - Refer to ISO 14229-1 for negative response format and codes. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0093 | Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0259 | 5.5.8.2 Positive response | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0094 | 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request REQ_UDS 0265 5.5.10.1.1 Request parameter reportType Table 52 – Service 0x19 request parameter reportType description 0x01 reportNumberOfDTCByStatusMask M 0x02 reportDTCByStatusMask M 0x03 reportDTCSnapshotIdentification M 0x04 reportDTCSnapshotRecordByDTCNumber M 0x06 reportDTCExtendedDataRecordByDTCNumber M 0x0F reportMirrorMemoryDTCByStatusMask U | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0095 | Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNumberOfMirrorMemoryDTCByStatusMask U 0x12 reportNumberOfEmissionsRelatedOBDDTCByStatusMask E 0x13 reportEmissionsRelatedOBDDTCByStatusMask E 0x42 reportWWHOBDDTCByMaskRecord E 0x55 reportWWHOBDDTCWithPermanentStatus E Legislated OBD relevant ECUs have to support legislated OBD standards. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00629 | Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6-0xE: Reserved 0xF: Not available Bits 4-7 (alive reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6: Stay alive 0x7-0xE: Reserved 0xF: Not available Note 1: While the reason for keeping the ECU alive may change during execution startup reason and alive reason are always identical at ECU startup. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0103 | 5.5.11.1.2 Request parameter controlOptionRecord - Table 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 .. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0104 | 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameter - Table 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0105 | 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request REQ_UDS 0287 5.5.12.1.1 Request parameter RoutineControlType Table 60 – Service 0x31 request parameter RoutineControlType description 0x01 startRoutine M 0x02 stopRoutine C 0x03 requestRoutineResults C C = Mandatory for routines implemented according to Method “A”. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0107 | Internal Page 56 (90) - Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes ReadDiagnosticEventCodesByStatus ReadEventCodeData These routine IDs are used to handle diagnostic event codes and only mandatory when these type of data are used. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00652 | INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0113 | M 5.5.13.2 Request parameter dataFormatIdentifier - Table 63 – Service 0x34 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0114 | Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.13.3 Request parameter addressAndLengthFormatIdentifier Table 64 – Service 0x34 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.13.4 Positive response REQ_UDS 0115 Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3.. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0116 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifier - Table 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0117 | Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 Request - Table 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 .. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0118 | M 5.5.14.1.1 Request parameter dataFormatIdentifier - Table 68 – Service 0x35 request parameter dataFormatIdentifier description Bytes Description Cvt Values compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0120 | 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifier - Table 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0295 | 5.5.15 TransferData (0x36) service 5.5.15.1 Request | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0123 | 5.5.16.2 Positive response - Table 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID M | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0134 | 5.5.18.1 Request - Refer to CVS31 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0135 | 5.5.18.2 Request parameter subFunction - Refer to CVS31 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0136 | 5.5.18.3 Positive response - Refer to CVS31 . | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00704 | INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0163 | 5.6.2.1 Request - Table 78 – RoutineIdentifier 0xFF00 description #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x00 #5 addressAndLengthFormatIdentifier (XXXXYYYYb) XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0167 | 255 – System specific 5.6.2.3 Positive response - Table 80 – RoutineControl (EraseMemory) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) eraseMemory [byte#1] M 0xFF #4 routineIdentifier (LSB) eraseMemory [byte#2] M 0x00 #5 routineStatus routineResult M 0x00-0xFF | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0169 | Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0xFF #4 routineIdentifier (LSB) 0x00 Example #2: Negative response: server → client Table 87 – Example #2: Negative response: server → client #1 Negative Response 0x7F #2 RoutineControl Response SID 0x31 #3 conditionsNotCorrect 0x22 5.6.3 Routine 0x2401 – Software Installation The RoutineIdentifier may verify the authenticity of the received file package. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0208 | The timestamp is presented in SAE J1939-71 format without local hour/minute offsets. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0209 | In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified: Table 98 – J1939-71 timestamp format Byte No Length Name Resolutio n Offset Note 1 1 byte Seconds 0.25 s/bit 0 2 1 byte Minutes 1 min/bit 0 3 1 byte Hours 1 hr/bit 0 4 1 byte Month 1 month/bit 0 Value 1 identifies January, value 2 identifies February and so on 5 1 byte Day 0.25 days/bit 0 Values 1,2,3 and 4 identifes first day of month, value 5,6,7,8 identifies second day of month and so on 6 1 byte Year 1 year/bit 1985 Value of 0 identifies year 1985, value of 1 identifes year 1986 and so on 7 1 byte Local minute offset 1 min/bit -125 Not used in DTC timestamps 8 1 byte Local hour offset 1 hr/bit -125 Not used in DTC timestamps | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0215 | 5.7.4.1 Latest occurrence - The latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0216 The latest distance value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0217 | 5.7.4.2 First occurrence - The first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3 | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0218 | The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0220 | 5.7.5.1 Latest occurrence - The latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0221 | The latest operational hours value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0222 | 5.7.5.2 First occurrence - The first operational hours value is updated at the first change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ_UDS-0003 | Modified requirements - Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00785 | RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00843 | Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00859 | However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00880 | Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00932 | AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00947 | While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00988 | Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-00996 | (There may be more than one authentication state). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-01013 | SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |
| REQ-AUTO-01056 | The SDT positive response may of course contain an encapsulated negative UDS response. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm if binding |