Detailed Requirements

Full original requirement statement: 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.

Full original requirement statement: Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity.

Full original requirement statement: Risk assessment REQ_SEC_0002 The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations.

Full original requirement statement: Method and scope shall be proposed to and approved by the vehicle manufacturer.

Full original requirement statement: Documentation on the method and results shall be provided to the vehicle manufacturer.

Full original requirement statement: Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively.

Full original requirement statement: Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk analyses shall be evaluated.

Full original requirement statement: For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.

Full original requirement statement: REQ_SEC_0023 Cybersecurity controls shall sufficiently reduce the risk.

Full original requirement statement: It shall be possible to verify which cybersecurity controls were derived from which requirements.

Full original requirement statement: 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.

Full original requirement statement: Verification and validation REQ_SEC_0004 The supplier shall provide documentation of the verification and validation methods of cybersecurity features.

Full original requirement statement: REQ_SEC_0005 The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features.

Full original requirement statement: Documentation REQ_SEC_0007 An inventory of software and protocols, including their versions, shall be provided by the supplier.

Full original requirement statement: Marcus Lindner EPXC Published 7(16) REQ_SEC_0025 A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier.

Full original requirement statement: 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.

Full original requirement statement: Software security REQ_SEC_0008 The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU.

Full original requirement statement: Methods shall be proposed to and approved by the vehicle manufacturer.

Full original requirement statement: Security architecture REQ_SEC_0009 The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach.

Full original requirement statement: Cryptographic libraries REQ_SEC_0020 Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier.

Full original requirement statement: Services REQ_SEC_0010 All network services implemented in the ECU shall undergo hardening.

Full original requirement statement: REQ_SEC_0011 The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer.

Full original requirement statement: Interfaces REQ_SEC_0012 Communication interfaces shall use boundary controls such as ingress/egress filtering.

Full original requirement statement: REQ_SEC_0013 Communication boundary controls shall be configurable by the vehicle manufacturer.

Full original requirement statement: Methods shall be proposed and approved by the vehicle manufacturer.

Full original requirement statement: REQ_SEC_0014 Any interfaces used for development purposes shall be removed or disabled in series production.

Full original requirement statement: The details shall be agreed upon between the vehicle manufacturer and the supplier.

Full original requirement statement: REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.

Full original requirement statement: Information security REQ_SEC_0027 It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer.

Full original requirement statement: Marcus Lindner EPXC Published 9(16) REQ_SEC_0028 Data specified by the vehicle manufacturer shall be protected from manipulations.

Full original requirement statement: REQ_SEC_0029 Data specified by the vehicle manufacturer shall be protected from disclosure.

Full original requirement statement: REQ_SEC_0006 Intellectual property of the vehicle manufacturer shall be protected from disclosure.

Full original requirement statement: Key management REQ_SEC_0016 It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer.

Full original requirement statement: 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.

Full original requirement statement: REQ_SEC_0021 ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier.

Full original requirement statement: REQ_SEC_0015 ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer.

Full original requirement statement: Security updates REQ_SEC_0043 It shall be possible to update the software of the ECU.

Full original requirement statement: Marcus Lindner EPXC Published 10(16) REQ_SEC_0030 The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available.

Full original requirement statement: Incident management REQ_SEC_0044 An incident response process shall be proposed to and approved by the vehicle manufacturer.

Full original requirement statement: REQ_SEC_0045 In case of cybersecurity incidents, the incident response process shall be used.

Full original requirement statement: REQ_SEC_0046 The incident response process shall be maintained for the entire product lifetime.

Full original requirement statement: REQ_SEC_0032 The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer.

Full original requirement statement: Vulnerability management REQ_SEC_0033 Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer.

Full original requirement statement: The report shall include information needed to identify the affected vehicles/products.

Full original requirement statement: Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer.

Full original requirement statement: REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.

Full original requirement statement: Marcus Lindner EPXC Published 11(16) REQ_SEC_0035 Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability.

Full original requirement statement: 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.

Full original requirement statement: Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer.

Full original requirement statement: REQ_SEC_0036 The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product.

Full original requirement statement: REQ_SEC_0037 Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring.

Full original requirement statement: Product lifecycle REQ_SEC_0047 An ECU returned from field shall allow for field-return analysis.

Full original requirement statement: REQ_SEC_0048 Field-return analysis secrets shall not be operational in the field.

Full original requirement statement: REQ_SEC_0049 An ECU enabled for field-return analysis shall not be possible to use as a spare part.

Full original requirement statement: Marcus Lindner EPXC Published 12(16) REQ_SEC_0050 All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.

Full original requirement statement: End-of-life and decommissioning shall be specifically considered.

Full original requirement statement: Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer.

Full original requirement statement: b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer.

Full original requirement statement: Logging REQ_SEC_0051 Security related events shall be identified and logged.

Full original requirement statement: 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.

Full original requirement statement: P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven.

Full original requirement statement: 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.

Full original requirement statement: 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).

Full original requirement statement: The variant type shall be based on delivery agreement and Brand involved.

Full original requirement statement: 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.

Full original requirement statement: The marking shall not be visible when the ECA is mounted on a gearbox.

Full original requirement statement: The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews.

Full original requirement statement: 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification.

Full original requirement statement: 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc.

Full original requirement statement: 2.12 Traton requires: - Documentation of the product, i.e.

Full original requirement statement: Should the PP be fully calculated from the AP-sensor, then this offset should not exist.

Full original requirement statement: 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.

Full original requirement statement: 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm.

Full original requirement statement: 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435

Full original requirement statement: P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins.

Full original requirement statement: 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.

Full original requirement statement: The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing.

Full original requirement statement: 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand.

Full original requirement statement: 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached.

Full original requirement statement: 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req.

Full original requirement statement: 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.

Full original requirement statement: P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools.

Full original requirement statement: If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Details regarding actual length and positioning tolerances shall be agreed in design phase.

Full original requirement statement: 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.

Full original requirement statement: 4.23 The actuator shall apply a preload force for the release bearing.

Full original requirement statement: 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).

Full original requirement statement: 4.25 It must be possible to assemble the actuator independent of the lever position without any power connection.

Full original requirement statement: This means that the push rod shall be possible to move by hand.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time

Full original requirement statement: 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).

Full original requirement statement: This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time

Full original requirement statement: P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14).

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm.

Full original requirement statement: 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.

Full original requirement statement: The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request.

Full original requirement statement: 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.

Full original requirement statement: Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position.

Full original requirement statement: 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm.

Full original requirement statement: Maximum overshoot is 0.2 mm When a new position is requested, but the stroke is too short to reach requested speed, the ECA shall complete the stroke in minimum time with dynamic in compliance with the req 5.1, 5.2 and this section.

Full original requirement statement: 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle.

Full original requirement statement: 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.

Full original requirement statement: 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

Full original requirement statement: Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement.

Full original requirement statement: The strategy shall be disc ussed and approved with Traton.

Full original requirement statement: 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.

Full original requirement statement: This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req.

Full original requirement statement: P 1 Page 6 SW functionality 6.1 TB4684 shall be applied.

Full original requirement statement: It shall be followed to its full extent.

Full original requirement statement: When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP).

Full original requirement statement: Specific cases shall be approved with Traton.

Full original requirement statement: 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).

Full original requirement statement: Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque.

Full original requirement statement: 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults.

Full original requirement statement: 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.

Full original requirement statement: CAN communication shall still be active.

Full original requirement statement: If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit.

Full original requirement statement: 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified.

Full original requirement statement: The value of the FCCP shall be reported via CAN(Ref 14.14) Req.

Full original requirement statement: The value shall be frozen at the last identified position and used for RPC.

Full original requirement statement: 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.

Full original requirement statement: 6.11 SW number: The ECA shall report a complete SW version number.

Full original requirement statement: 6.12 HW number: The ECA shall report a complete HW version number.

Full original requirement statement: 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.

Full original requirement statement: ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults .

Full original requirement statement: 6.14 System state The ECA shall report its current System State.

Full original requirement statement: 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state.

Full original requirement statement: 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control.

Full original requirement statement: 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control.

Full original requirement statement: 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state.

Full original requirement statement: 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation.

Full original requirement statement: 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.

Full original requirement statement: (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator.

Full original requirement statement: These values shall be calculated using a moving mean filter.

Full original requirement statement: The filter time shall equal the update frequency .

Full original requirement statement: (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage.

Full original requirement statement: (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.

Full original requirement statement: 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length.

Full original requirement statement: 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12).

Full original requirement statement: 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind.

Full original requirement statement: P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated.

Full original requirement statement: 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.

Full original requirement statement: If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally.

Full original requirement statement: 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events.

Full original requirement statement: 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.

Full original requirement statement: 7.2 Short circuit protection shall be implemented by hardware.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded.

Full original requirement statement: If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded.

Full original requirement statement: 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.

Full original requirement statement: All power used by the ECA shall be taken from this battery connection.

Full original requirement statement: The ground shall not be DC connected to the ECA housing.

Full original requirement statement: 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions.

Full original requirement statement: It shall be used to control the power up sequence to the µP.

Full original requirement statement: The Wake-up signal shall also be connected to a digital input on the µP.

Full original requirement statement: Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: Redundancies due improper shutdown shall be aligned with Traton.

Full original requirement statement: If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request.

Full original requirement statement: Any watchdog circuit shall have no influence on the CAN bus.

Full original requirement statement: The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter.

Full original requirement statement: 7.35 The controller and transceiver shall be CAN FD ready.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: The components shall not be populated by default.

Full original requirement statement: The CAN front end shall be designed to comply with TB1905.

Full original requirement statement: The quality of the wire bonding and position shall be properly analyzed.

Full original requirement statement: The material shall be lead free and of ”high temperatures solder type”.

Full original requirement statement: The melting point of the soldering material and the composition of the soldering material shall be declared by supplier.

Full original requirement statement: The PCB must be supported and must not bent in any direction during the process.

Full original requirement statement: Conformal coating or lacquer shall cover the entire PCB and all solder joints.

Full original requirement statement: 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.

Full original requirement statement: shall be specified in the initial offer.

Full original requirement statement: The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g.

Full original requirement statement: 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.

Full original requirement statement: Water based and silicone lacquers shall not be used.

Full original requirement statement: 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane.

Full original requirement statement: 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.

Full original requirement statement: The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water.

Full original requirement statement: The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane.

Full original requirement statement: 7.46 Forbidden components: BGA capsule in any form must not be used.

Full original requirement statement: Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used.

Full original requirement statement: 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B.

Full original requirement statement: 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life.

Full original requirement statement: Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life.

Full original requirement statement: 8.5 The ECA must be maintenance free over the whole life time.

Full original requirement statement: 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.

Full original requirement statement: Spare parts or repair kits shall be defined together in agreement.

Full original requirement statement: 4.17) shall be provided as a spare part.

Full original requirement statement: 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.

Full original requirement statement: ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868.

Full original requirement statement: 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.

Full original requirement statement: The different parts of the housing shall be marked according to material content.

Full original requirement statement: The ECA shall be lead free.

Full original requirement statement: ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval.

Full original requirement statement: For type approval, the vehicle and its components shall comply with ECE Regulation No.

Full original requirement statement: P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).

Full original requirement statement: 10.2 The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).

Full original requirement statement: CAN communication shall not be affected.

Full original requirement statement: Memory functions shall remain Class A.

Full original requirement statement: Accepted behaviour in this case shall be agreed upon between Traton and Supplier.

Full original requirement statement: P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure II shall be used: Test procedure I A comprehensive test where all functional requirements are verified.

Full original requirement statement: This test shall be performed before and after exposure.

Full original requirement statement: Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified.

Full original requirement statement: This test shall be possible to perform during exposure.

Full original requirement statement: 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.

Full original requirement statement: tab headers) shall be made of self- extinguishing materials (i.e.

Full original requirement statement: P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such.

Full original requirement statement: The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety".

Full original requirement statement: The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262.

Full original requirement statement: For this purpose possible causes must be systematically identified.

Full original requirement statement: For these analyses at least the methods in ISO 26262 shall be applied.

Full original requirement statement: ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O.

Full original requirement statement: This test must verify that all internal and external I/O fulfils the requirements in this specification.

Full original requirement statement: 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.

Full original requirement statement: the suppler must carry out two full test rounds according to the Traton test requirements.

Full original requirement statement: Additional tests initiated and performed by the supplier must be discussed with Traton.

Full original requirement statement: A3 The supplier must test the connectors according to TB1787.

Full original requirement statement: A4 The supplier must do EMC tests with the unit alone.

Full original requirement statement: The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments.

Full original requirement statement: A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings.

Full original requirement statement: A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-STD-001 class 3 and IPC-A-610 class 3.

Full original requirement statement: 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.

Full original requirement statement: However, dividing sample phases into several generations must be agreed upon between Traton and the supplier.

Full original requirement statement: All samples shall be functionally tested before sent to Traton.

Full original requirement statement: Deviations shall be reported as a part of the sample delivery.

Full original requirement statement: Dimensional checks shall be performed for B and C-samples prior to delivery to Traton.

Full original requirement statement: The supplier must use the sample denominations requested by Traton.

Full original requirement statement: 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.

Full original requirement statement: The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.

Full original requirement statement: Between the two movements the actuator should remain in the fully disengaged position.

Full original requirement statement: After the complete engagement the actuator should remain in this position until the next disengagement is requested.

Full original requirement statement: • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C 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/80C 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.

Full original requirement statement: Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.

Full original requirement statement: The User shall apply the latest version of this CVS123-2.

Full original requirement statement: 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.

Full original requirement statement: SUV2_INFO 8 It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers.

Full original requirement statement: For this reason, only the server is required to support the specified sequence.

Full original requirement statement: Application data module (Calibration data) Contains a variant-specific set of parameter values that is required for correct operation of the control unit in a specific vehicle variant.

Full original requirement statement: It must be clearly separated from the application software.

Full original requirement statement: For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software.

Full original requirement statement: Application software module Contains all vehicle functions required for the normal server operation.

Full original requirement statement: 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.

Full original requirement statement: shall be implemented in the boot software code.

Full original requirement statement: The value of this variable may be used by the application to determine whether or not initialization is required.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s).

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten.

Full original requirement statement: If the microcontroller supports HW protection, this shall be used.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours.

Full original requirement statement: 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).

Full original requirement statement: SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs.

Full original requirement statement: 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”.

Full original requirement statement: When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197

Full original requirement statement: SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”.

Full original requirement statement: SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer.

Full original requirement statement: SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files.

Full original requirement statement: SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure.

Full original requirement statement: SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer.

Full original requirement statement: SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site.

Full original requirement statement: SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values.

Full original requirement statement: Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124.

Full original requirement statement: Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter.

Full original requirement statement: 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).

Full original requirement statement: SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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).

Full original requirement statement: SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9.

Full original requirement statement: 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.

Full original requirement statement: SUV2_INFO 93 If the application was started, it checks if application initialization is required.

Full original requirement statement: 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.

Full original requirement statement: SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer.

Full original requirement statement: SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot.

Full original requirement statement: SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration.

Full original requirement statement: SUV2_REQ 37 Application software and application data modules shall be programmable in any order.

Full original requirement statement: SUV2_REQ 38 The server shall be able to update an individual module independently from any other module.

Full original requirement statement: SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented.

Full original requirement statement: SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm.

Full original requirement statement: SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer.

Full original requirement statement: SUV2_REQ 42 It shall be possible to program the same software version repeatedly.

Full original requirement statement: SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application.

Full original requirement statement: SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values.

Full original requirement statement: SUV2_REQ 45 If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module.

Full original requirement statement: Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot parameter module has been successfully programmed, the boot loader shall read and apply these parameter values from the boot parameter module.

Full original requirement statement: Otherwise if no boot parameter module has been successfully programmed, the boot loader shall apply the corresponding parameter values persisted in the boot loader module.

Full original requirement statement: Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9.

Full original requirement statement: SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer.

Full original requirement statement: SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: The causes specified in (ISO14229-1:2020) shall be regarded as examples.

Full original requirement statement: SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted.

Full original requirement statement: 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124.

Full original requirement statement: SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported.

Full original requirement statement: Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data SUV2_REQ 55 ECU identification data support shall be as per CVS124.

Full original requirement statement: 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).

Full original requirement statement: SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed in supplier premises, even if a software update capability is required in vehicle manufacturer production premises, e.g., for bug fixing.

Full original requirement statement: 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).

Full original requirement statement: 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4.

Full original requirement statement: 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.

Full original requirement statement: 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).

Full original requirement statement: SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error.

Full original requirement statement: 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

Full original requirement statement: Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.

Full original requirement statement: SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC.

Full original requirement statement: SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC.

Full original requirement statement: SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01.

Full original requirement statement: 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5.

Full original requirement statement: Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6.

Full original requirement statement: #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.

Full original requirement statement: 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.

Full original requirement statement: SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed.

Full original requirement statement: SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed.

Full original requirement statement: 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7.

Full original requirement statement: Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020.

Full original requirement statement: 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decryption of data, the server shall return NRC 0x10.

Full original requirement statement: 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.

Full original requirement statement: Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020.

Full original requirement statement: 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter.

Full original requirement statement: 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32.

Full original requirement statement: 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020.

Full original requirement statement: Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020.

Full original requirement statement: 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32.

Full original requirement statement: 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.

Full original requirement statement: 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32.

Full original requirement statement: 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.

Full original requirement statement: 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.