Tiêu chuẩn iso 15765 4 2016

Figure 1 — Dia nostic communication o er CAN document reference ac ording to OSI model6 Ex ter nal test equipment initial zation sequenc e The ext ernal t es eq ipment hal sup ort he ini

Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 15765-2 apply.

Symbols

CAC1, CAC2 capacitance of a.c termination F

CCAN_H capacitance between CAN_H and ground potential F

CCAN_L capacitance between CAN_L and ground potential F

CDIFF capacitance between CAN_H and CAN_L F Δf oscillator tolerance Hz lCABLE maximum cable length between OBD/WWH-OBD connector and external test equipment m

RAC1, RAC2 resistance of a.c termination Ω

The Sync_Seg synchronization segment is defined by tBIT, which represents the bit time This includes tBIT_RX for the receive bit time and tBIT_TX for the transmit bit time Additionally, tCABLE refers to the cable propagation delay when external test equipment is not utilized.

The CAN interface includes several key timing parameters: tSEG1 represents timing segment 1, tSEG2 denotes timing segment 2, and tSJW refers to the resynchronization jump width Additionally, tSYNCSEG is the synchronization segment, while tTOOL pertains to external test equipment It's important to note that the CAN interface propagation delay is measured without considering the external test equipment cable delay, and tQ indicates the time quantum.

Abbreviated terms

DoCAN diagnostic communication over CAN

WWH-OBD world-wide harmonized on-board diagnostics

ISO 15765 is based on the conventions specified in the OSI Service Conventions (ISO/IEC 10731:1994) as they apply for diagnostic services.

Figure 1 — Diagnostic communication over CAN document reference according to OSI model

6 External test equipment initialization sequence

General

The external test equipment shall support the initialization sequence specified in this part of ISO 15765 (see Figure 2).

The external test equipment initialization sequence aims to automatically identify if the vehicle complies with the mandated OBD or WWH-OBD standards on CAN, utilizing the physical layer outlined in Clause 12.

Furthermore, the initialization sequence determines the communication compliance status of vehicles by analysing their responses to

— ISO 15031-5 service 01 16 00 16 (PID supported) requests, or

— ISO 27145-3 service 22 16 F8 16 10 16 (DID protocol identification) request with a positive response.

Only vehicles adhering to the WWH-OBD regimen will have ECUs that respond to the functional request service 22 16 DID F810 16 for protocol identification In contrast, vehicles that only respond to the functional request service 01 16 PID 00 16 utilize earlier OBD communication methods Vehicles that do not respond to either request do not support regulated OBD diagnostics as outlined in ISO 15765 The procedure is detailed in section 6.3.

To ensure accurate data parameter requests for legislated OBD/WWH-OBD services, external test equipment must first update its list of expected responding ECUs For detailed information on applicable services, refer to ISO 15031-5 for legislated OBD and ISO 27145-3 for legislated WWH-OBD.

The external test equipment initialization sequence supports single baudrate initialization (e.g

500 kBit/s) and multiple baudrate initialization (e.g 250 kBit/s and 500 kBit/s) and is separated into the following tests: a) 11 bit CAN identifier validation; b) 29 bit CAN identifier validation.

The external test equipment initialization sequence accommodates legacy vehicles by utilizing either CAN, as defined for legislated OBD/WWH-OBD, or an alternative non-CAN protocol on the CAN pins of the ISO 15031-3 diagnostic connector.

Figure 2 — Initialization sequence overview 6.2 and 6.3 describe the external test equipment initialization to determine baudrate and CAN identifier

(11 bit or 29 bit) for OBD (ISO 15031) and WWH-OBD (ISO 27145).

Baudrate validation procedure

BaudrateRecord

The default parameter "baudrateRecord" includes all baud rates listed in section 12.3, but it can be replaced by an alternative list, such as a single baud rate of 500 kBit/s as detailed in section 12.3.3.

The baudrateRecord parameter determines the type of initialization process For a single baudrate, a corresponding initialization sequence will be executed, such as 500 kBit/s In cases where multiple baudrates are specified, a multiple-baudrate initialization sequence will take place, which includes a baudrate detection procedure as illustrated in Figure 4.

Figure 3 will be executed at designated multiple baud rates, such as 250 kBit/s and 500 kBit/s For compliant OBD/WWH-OBD baud rates, the external testing equipment must utilize the correct CAN bit timing parameters as outlined in section 12.3.

Baudrate validation

When multiple baud rates are provided in the baudrateRecord parameter, the procedure outlined in Figure 3 will be utilized to select the appropriate baud rate for communication with the vehicle.

The external test equipment must configure its CAN interface using the initial baud rate specified in the baudrateRecord, applying the CAN bit timing parameters associated with this baud rate as outlined in section 12.3.

After setting up the CAN interface, the external test equipment must connect to the CAN bus and promptly send a functionally addressed request message using service 0116 (to read supported PIDs) This should be done with the legislated OBD/WWH-OBD 11-bit functional request CAN identifier as specified in section 10.5.2.

Immediate transmission is essential to activate CAN error monitoring, as initializing the CAN controller at an incorrect baud rate without data transmission can cause the controller to generate error frames on the CAN bus.

The external test equipment must verify any CAN errors Upon successful transmission of the request message onto the CAN bus, it will indicate a successful transmission and continue with the validation of the CAN identifier as outlined in section 6.3.

If an acknowledgment (ACK) check error occurs, the external test equipment will persist in retrying the transmission of the request message until the 25 ms timeout (N_As) is reached.

If a CAN error arises or an acknowledgment check error persists beyond the 25 ms (N_As) timeout, the external test equipment must disconnect its CAN interface from the CAN bus.

5 Proceed with sequence according to Figure 4.

The external test equipment must verify if additional baud rates are present in the baudrateRecord If the end of the baudrateRecord has not been reached, the equipment should configure its CAN interface with the next baud rate and restart the validation process as outlined in step (1) of Figure 3 If no further baud rates are available in the baudrateRecord, it will be concluded that the request was not successfully transmitted, indicating non-compliance with ISO 15765 and ISO 27145-4 standards.

External test equipment error detection provisions

If a vehicle employs a CAN with a physical layer that differs from the OBD/WWH-OBD specifications or utilizes a non-CAN protocol on the OBD/WWH-OBD connector's CAN pins, the transmit procedure outlined in ISO 15765 ensures that external test equipment will recognize the vehicle's lack of support for the legislated CAN standards for OBD/WWH-OBD Consequently, the transmission of the request message will be halted immediately.

In vehicles utilizing CAN with a physical layer as per Clause 12, the transmission procedure ensures that external test equipment will promptly identify any incorrect baud rate used for request message transmission, thereby ceasing interference with the CAN bus Under standard in-vehicle conditions, where no error frames occur during communication with the external test equipment disconnected, this equipment will deactivate its CAN interface before the internal error counters of the mandated OBD/WWH-OBD ECU(s) reach critical levels.

To achieve this, the external test equipment shall implement the following provisions:

— possibility to immediately stop sending during transmission of any CAN frame;

— the CAN interface should be disconnected within 12 às from reception of a bus frame error signal The maximum time for the disconnection is 100 às;

— with the CAN interface disconnected, the external test equipment shall not be able to transmit dominant bits on the CAN bus;

— possibility to immediately detect any frame error on the CAN bus.

The second provision indicates that external test equipment should not depend exclusively on standard CAN controller error handling, as it typically identifies a frame error only after entering the "bus-off" state (see ISO 11898-1 for more information).

CAN identifier validation procedure

CAN identifier validation procedure OBD

The response handling procedure is designed to manage 11-bit CAN identifier response messages from mandated OBD ECUs, as well as to signal when no response has been received Additionally, if legislated OBD-related ECUs are identified, this procedure compiles a list of the available ECUs in the OBD-compliant vehicle.

The response validation procedure shall be performed as defined in Figure 4, after the 11 bit CAN identifier request message transmit procedure (see Figure 3) has succeeded (“OK”). © ISO 2016 – All rights reserved 9

Upon successful transmission of the request message, indicated by an "OK" response, the external test equipment will initiate the P2CAN_Client application timer and monitor the physical response CAN identifiers as specified in section 10.5.

If the external test equipment detects a P2CAN timeout without a response message, it confirms that the 11-bit or 29-bit CAN identifiers used in the previous request are not applicable for legislated OBD communication This indicates that the vehicle is compatible with CAN, utilizing the specified physical layer and the baud rate defined in the baudrateRecord parameter.

The initiation of a response message can occur through the reception of either a FirstFrame or SingleFrame, utilizing the designated OBD 11 bit or 29 bit CAN identifiers from the previous request Once a response message begins, external test equipment must continue to receive this ongoing response, applicable only to multiple-frame messages, and can accept additional response messages within P2CAN_Client that also use the specified 11 bit or 29 bit physical response CAN identifiers from the prior request.

Once all initial response messages, both positive and negative, are fully received and the timer for the P2CAN_Client application has expired, the external test equipment will evaluate the presence of any negative responses.

If negative responses with response code 2116 (busyRepeatRequest) are received, the external test equipment must restart the response validation procedure after a minimum delay of 200 ms Should negative responses occur in six consecutive sequences, the equipment will conclude that the vehicle does not comply with ISO 15031-5 Consequently, an OBD-compliant system is required to provide a positive response within a maximum of five retries.

Assuming that each negative response with NRC 2116 is received shortly before P2 elapses, the total time available for the vehicle to correctly respond results in 1 250 ms.

If a legislated OBD ECU generates any negative response code or provides an uninterpretative response per ISO 15031-5, the external test equipment will conclude that the vehicle does not comply with ISO 15031-5, indicating a "NOT OK" status.

If no negative or invalid response is detected, the external test equipment confirms that the vehicle supports either 11-bit or 29-bit CAN identifiers for OBD communication It then compiles a list of the legislated OBD-related ECUs that responded to the service 0116 request and reads the supported PIDs based on the physical responses received This step concludes the initialization sequence and verifies the vehicle's compliance with ISO 15765.

If the support for 11-bit CAN identifiers in legislated OBD communication is unverified, a functionally addressed request message with service 0116 (read supported PIDs) must be sent using the legislated OBD 29-bit functional request CAN identifier as outlined in section 10.5.3 The response validation procedure should then be repeated as shown in Figure 4 If neither 11-bit nor 29-bit CAN identifiers for legislated OBD communication are supported, the detection of WWH-OBD-compliant ECUs should proceed as specified in Figure 5.

7 Vehicle is compliant with this part of ISO 15765.

Figure 4 — Perform ISO 15031-5 OBD response validation

CAN identifier validation procedure WWH-OBD

A service request for protocol identification, identified by the legislated WWH-OBD 11-bit functional request CAN identifier as specified in section 10.5.2, must be transmitted, and the response validation procedure should follow the guidelines outlined in Figure 5.

Upon successful transmission of the WWH-OBD request message, the external test equipment will initiate the P2CAN_Client application timer and monitor the physical response CAN identifiers as specified in ISO 27145-3 and section 10.5.

If the external test equipment detects a P2CAN timeout, it indicates that no response message has been initiated Additionally, the equipment confirms that the 11-bit or 29-bit CAN identifiers, used in the previously sent request message, are not applicable for mandated WWH-OBD communication.

The initiation of a response message can occur through the reception of either a FirstFrame or SingleFrame, utilizing the designated 11-bit or 29-bit CAN identifiers as specified in the previous request message Once a response message has begun, external test equipment must continue to receive this ongoing response, applicable only to multiple-frame responses, and must also accept additional response messages within P2CAN_Client that employ the same specified physical response CAN identifiers from the prior request.

Once all response messages, both positive and negative, are received and the P2CAN_Client application timer has expired, the external test equipment will analyze the responses If any negative responses with the code 2116 (busyRepeatRequest) are detected, the validation procedure will restart after a minimum delay of 200 ms Should negative responses occur in six consecutive sequences, the equipment will conclude that the vehicle does not comply with ISO 27145-3, indicating that a legislated WWH-OBD-compliant system must provide a positive response within five retries.

Assuming that each negative response with NRC 2116 is received shortly before P2 elapses, the total time available for the vehicle to correctly respond results in 1 250 ms.

If a legislated WWH-OBD ECU generates a negative response code or an unrecognizable response according to ISO 27145-3, the external testing equipment will determine that the vehicle does not comply with ISO 27145-3 standards.

If no negative or invalid response was detected, the external test equipment confirms that the vehicle supports either 11 bit or 29 bit CAN identifiers for WWH-OBD communication It will compile a list of the legislated WWH-OBD-related ECUs that responded to service request 22 16 F81016 and subsequently read the supported DIDs based on the physical responses received.

If the list contains at least one WWH-OBD-compliant ECU, the initialization sequence is finished and it is verified that the vehicle is ISO 27145-4 compliant.

If the list lacks at least one WWH-OBD-compliant ECU, it is assumed that the vehicle does not support the CAN identifier referenced in the earlier request.

If the 11-bit CAN identifiers for WWH-OBD communication cannot be verified, a request message using service 2216 (read supported PIDs) must be sent with the 29-bit functional request CAN identifier Following the successful transmission of this request, external test equipment should repeat the response validation sequence If neither the 11-bit nor the 29-bit CAN identifier is verified as supported, it will be concluded that the vehicle does not comply with ISO 27145.

Figure 5 — Perform ISO 27145-3 WWH-OBD response validation

The application layer, the seventh level of the OSI model, directly interfaces with application processes and provides essential application services It also communicates requests to the presentation layer.

The application layer for the emissions-related diagnostic services shall be implemented as defined in the following:

— legislated OBD: diagnostic services as defined in ISO 15031-5;

— legislated WWH-OBD: diagnostic services as defined in ISO 27145-3.

— legislated OBD shall respond to ISO 15031-5 requests from the external test equipment, and

— legislated WWH-OBD shall respond to ISO 27145-3 requests from the external test equipment.

The external test equipment must support a specified list of detected legislated OBD/WWH-OBD-related ECUs, which are generated during the initialization sequence as outlined in Clause 6.

ISO 14229-2 defines the session layer service requirements.

All legislated OBD/WWH-OBD communication shall take place during the default diagnostic session.

In a legislated OBD-related ECU, there must be only one active diagnostic session at any given time Upon powering up, the ECU will automatically initiate the default diagnostic session If no alternative diagnostic session is activated, the default session will continue to operate for the duration of the ECU's power.

A legislated OBD/WWH-OBD ECU shall be capable of providing all diagnostic functionality defined for legislated OBD/WWH-OBD in the default diagnostic session and under normal operating conditions.

There is no need for any diagnostic service to be sent to the legislated OBD/WWH-OBD ECU(s) to keep the default diagnostic session active.

ISO 15765-2 requirements apply to legislated OBD purposes, excluding the use of CAN FD Furthermore, the FirstFrame escape sequence is permitted solely when utilizing ISO 14229-1 UDS services for legislated OBD.

General

The network layer of external test equipment and the OBD/WWH-OBD-compliant vehicle ECUs must comply with ISO 15765-2, along with the specific restrictions and additions outlined in sections 10.2 to 10.5.

Network layer parameters

Timing parameter values

Table 2 outlines the timing parameters for the network layer that external test equipment must utilize when communicating with OBD-compliant vehicles, specifically for OBD/WWH-OBD interactions.

The performance requirement values outlined are essential communication standards for external test equipment and the OBD/WWH-OBD ECU(s) deemed OBD-compliant To address situations where performance requirements may not be achievable due to factors like high bus load, the defined timeout values are set higher than the performance requirements.

Table 2 — Network layer timeout and performance requirement values

Parameter Timeout value Performance requirement value

According to ISO 15765-2, a comprehensive overview of the network layer timing parameter values is available Due to the timing requirements of the application layer, it is essential to meet the performance criteria for transmitting a single frame or the initial frame of an ECU response message, which is defined as P2CAN, ECU + N_As ⊣⫤ P2CAN_max.

Definition of Flow Control parameter values

The BlockSize (BS) and SeparationTime (STmin) parameters are constrained for external test equipment and the server/ECU However, despite these limitations, both must be able to adjust to any valid parameters within a FlowControl frame.

This implies that the external test equipment shall use these values when transmitting FlowControl frames, but will still need to support the transport protocol as defined in ISO 15765-2.

The external test equipment shall use the following network layer parameter values defined in Table 3 for its FlowControl frames sent in response to the reception of a FirstFrame.

Table 3 — External test equipment Flow Control parameter values

Legislated OBD/WWH-OBD does not permit FlowControl wait frames The FlowControl frame sent by external test equipment after the FirstFrame of an ECU response must have the FlowStatus (FS) set to 0 (ClearToSend), prompting the ECU to begin transmission immediately upon receiving the FlowControl frame.

During a segmented message transfer, external test equipment will transmit a single FlowControl frame, which will occur after the First Frame of an ECU response message.

STmin SeparationTime 0 This value allows the ECU to send ConsecutiveFrames, following the FlowControl frame sent by the external test equipment as fast as possible.

A reduced implementation of the ISO 15765-2 network layer in a legislated OBD/WWH-OBD ECU, which only addresses specific FlowControl frame parameter values (BS, ST min), will result in the receiving ECU ignoring any FlowControl frames that utilize different parameter values during OBD/WWH-OBD communication, treating them as unknown network layer protocol data units.

10.2.2.3 Legislated WWH-OBD server/ECU

The WWH-OBD server/ECU will utilize the network layer parameter values specified in Table 4 for the FlowControl frames that are transmitted in response to receiving a FirstFrame.

Table 4 — Legislated WWH-OBD server/ECU Flow Control parameter values

The server or ECU should determine the optimal value to meet the vehicle's network and gateway constraints To ensure the fastest transmission, it is advisable to use a value of zero.

EXAMPLE If an in-vehicle gateway can buffer eight messages, the

BS parameter value should be set to 8 to ensure that the external test equipment will not cause an overflow condition in the gateway’s buffer.

This value allows the external test equipment to send ConsecutiveFrames, following the FlowControl frame sent by a server/ ECU, as fast as supported by the WWH-OBD-compliant vehicle’s network.

The receiving server or ECU must provide a value for STmin that is compatible with the vehicle's network and gateway architecture Additionally, it should be able to receive CAN frames of the same transmission with an inter-frame time of zero milliseconds.

It must be ensured that vehicle networks and gateways can handle a maximum inter-frame separation time of 5 ms for long data transmissions to the server/ECU.

Maximum number of legislated OBD/WWH-OBD ECUs

10.2.3.1 Legislated OBD/WWH-OBD-related ECUs with 11 bit CAN identifiers

The maximum allowable number of legislated OBD/WWH-OBD ECUs with 11-bit CAN identifiers in a vehicle is eight Additionally, the external test equipment's network layer must be capable of receiving segmented data from these eight ECUs in parallel.

10.2.3.2 Legislated OBD/WWH-OBD-related ECUs with 29 bit CAN identifiers

Addresses specified in Table 5 are designated for legislated OBD/WWH-OBD ECUs utilizing 29-bit CAN identifiers The number of these ECUs that can respond to external test equipment compliant with ISO 15031-4/SAE J1978 or ISO 27145-6 is constrained solely by the available address ranges in Table 5 and the timing performance requirements for response messages (P2 Client_max).

The physical ECU diagnostic address (‘XX 16 ’) of an ECU embedded in the physical CAN identifiers shall be unique for an ECU in a given vehicle.

Table 5 — Physical ECU diagnostic addresses/ranges for 29 bit CAN identifiers

0016 – 3216 Vehicle manufacturer reserved address range

3416 – EF16 Vehicle manufacturer reserved address range

NOTE The addresses/ranges defined in Table 5 may also be used for ECUs which are not subject to legislative requirements.

Addressing formats

Normal and fixed addressing format

For legislated OBD/WWH-OBD communication, the following shall be used:

— only the normal addressing format (as defined in ISO 15765-2), in the case of 11 bit CAN identifiers;

— only the normal fixed addressing format (as defined in ISO 15765-2), in the case of 29 bit CAN identifiers.

Functional addressing

Functional addressed services require that the data content does not exceed the single frame limitation as defined in ISO 15765-2.

Figure 6 illustrates the functional request CAN identifier usage and related response.

Figure 6 — Functional request CAN identifier usage

Physical addressing

All WWH-OBD-related servers and ECUs must be able to receive physically addressed messages at the network layer, adhering to the maximum message length specified in ISO 27145-3 However, this requirement is not applicable to request messages related to ISO 15031-5.

The external test equipment must be able to send physically addressed request messages over the WWH-OBD-compliant network layer, adhering to the maximum message length specified in ISO 27145-3.

Figure 7 — Physical request CAN identifier usage

CAN identifier requirements

External test equipment

The external test equipment must accommodate both 11-bit and 29-bit CAN identifiers for compliant OBD/WWH-OBD communication It is essential that the equipment only accepts CAN identifiers that fall within the specified legislated ranges for these identifier types.

Legislated OBD/WWH-OBD server/ECU

From the external test equipment point of view, each legislated OBD/WWH-OBD ECU in a given legislated OBD/WWH-OBD-compliant vehicle shall

— support either 11 bit or 29 bit CAN identifiers for legislated OBD/WWH-OBD request and response messages;

— support one pair of physical request and response CAN identifiers in accordance with 10.5;

— accept the functional request CAN identifier of the supported CAN identifier set (11 bit or 29 bit, see 10.5) for functionally addressed legislated OBD/WWH-OBD request messages;

— accept the physical request CAN identifier associated with the physical response CAN identifier for physically addressed FlowControl frames sent by the external test equipment (see 10.5);

— accept the physical request CAN identifier for physically addressed SingleFrames or FirstFrames frames of the legislated OBD/WWH-OBD request messages sent by the external test equipment (see 10.5).

Mapping of diagnostic addresses

Legislated OBD/WWH-OBD CAN identifiers

The article outlines the specifications for 11 bit and 29 bit CAN identifiers essential for legislated OBD/WWH-OBD diagnostics It details how diagnostic addresses are mapped to CAN identifiers, as illustrated in Table 6, which categorizes these identifiers into physical and functional types For 11 bit CAN identifiers, the mapping of target address (TA) and source address (SA) to a CAN identifier is implied Additionally, Table 7 provides the specific 11 bit CAN identifiers designated for use in legislated OBD/WWH-OBD diagnostics.

Table 6 — Definition of diagnostic addresses versus type of CAN identifier

(TAtype) Message type (Mtype) Functional request Legislated OBD/WWH-OBD system = 3316

External test equipment = F116 functional diagnostics

Physical response External test equipment = F116 Legislated OBD/WWH-OBD

Physical request Legislated OBD/WWH-OBD

External test equipment = F116 physical diagnostics

XX 16 ECU physical diagnostic address.

NOTE For detailed descriptions of parameters TA, SA, TAtype and Mtype, see ISO 15765-2.

For legislated OBD/WWH-OBD:

The functional request CAN identifier is designated for functionally addressed request messages transmitted by external test equipment This specific CAN identifier corresponds to the TA 3316, which is part of the legislated OBD/WWH-OBD functional system, and SA F1 16, representing the external test equipment.

The physical response CAN identifier is designated for response messages that are physically addressed and sent by the mandated OBD/WWH-OBD ECU(s) This specific CAN identifier corresponds to TA F1 16, which is used for external test equipment, along with the physical diagnostic address (SA) of the ECU(s).

The physical request CAN identifier is designated for use in physically addressed request messages and all FlowControl frames transmitted by external test equipment This specific CAN identifier signifies the physical diagnostic address (TA) of the ECU and the SA F116 for the external test equipment.

The server identifier (physical diagnostic address) of a legislated OBD/WWH-OBD ECU shall be unique to a given legislated OBD/WWH-OBD-compliant vehicle.

The CAN identifiers specified for legislated OBD/WWH-OBD may also be used for enhanced diagnostics if this usage does not interfere with legislated OBD/WWH-OBD.

Table 7 — 11 bit legislated OBD/WWH-OBD CAN identifiers

7DF16 CAN identifier for functionally addressed request messages sent by external test equipment 7E016 Physical request CAN identifier from external test equipment to ECU #1

7E816 Physical response CAN identifier from ECU #1 to external test equipment

7E116 Physical request CAN identifier from external test equipment to ECU #2

7E916 Physical response CAN identifier from ECU #2 to external test equipment

7EA16 Physical response CAN identifier from ECU #3 to external test equipment

7EB16 Physical response CAN identifier ECU #4 to the external test equipment

7EC16 Physical response CAN identifier from ECU #5 to external test equipment

7ED16 Physical response CAN identifier from ECU #6 to external test equipment

7EE16 Physical response CAN identifier from ECU #7 to external test equipment

7EF16 Physical response CAN identifier from ECU #8 to external test equipment

While not required for current implementations, it is strongly recommended (and may be required by applicable legislation) that for future implementations, the following 11 bit CAN identifier assignments be used:

— 7E0 16 /7E8 16 for ECM (engine control module);

— 7E1 16 /7E9 16 for TCM (transmission control module).

Tables 8 and 9 outline the 29-bit CAN identifiers for legislated OBD/WWH-OBD, following the established mapping of diagnostic addresses These identifiers must adhere to the standard fixed addressing format as specified in ISO 15765-2, which is summarized in Table 8.

Table 8 — Summary of 29 bit CAN identifier format — Normal fixed addressing

Functional CAN identifier 1816 DB16 TA SA

Physical CAN identifier 1816 DA16 TA SA

Table 9 — 29 bit legislated OBD/WWH-OBD CAN identifiers

1816 DB16 3316 F116 Functional request CAN identifier from external test equipment to ECUs with #3316

1816 DA16 XX16 F116 Physical request CAN identifier from external test equipment to ECU #XX16

1816 DA16 F116 XX16 Physical response CAN identifier from ECU #XX16 to external test equipment

For future implementations, it is highly advisable to utilize the physical ECU addresses as specified in SAE J2178/1, as this may be mandated by relevant legislation.

The physical ECU diagnostic address of an ECU (‘XX16’) embedded in the physical CAN identifiers shall be unique for a legislated OBD/WWH-OBD ECU in a given vehicle.

Support of ECUNAME reporting

Each OBD-compliant server or ECU must respond to external test equipment that adheres to ISO 15031-4/SAE J1978 or ISO 27145-6 standards by supporting the InfoType "ECUNAME" as specified in SAE J1979-DA The external test equipment is responsible for mapping the server/ECU address to its corresponding name (ECUNAME) This requirement aims to supersede the previous recommendation outlined in Table 8 of SAE J2178.

All of ISO 11898-1 is applicable for legislated OBD/WWH-OBD purposes, with the following restrictions/additions The external test equipment CAN controller shall be able to transmit and receive

11 bit and 29 bit CAN identifiers (see 10.2).

The CAN DLC (Data Length Code) in every diagnostic CAN frame must always be set to 8, while the unused data bytes in a CAN frame remain undefined Any diagnostic CAN frame with a DLC value less than 8 is considered invalid.

8 shall be ignored by the receiving entity.

General

The physical layer and physical signalling of the external test equipment shall be in accordance with ISO 11898-1 and ISO 11898-2, with the restrictions and additions as specified in 12.2 through 12.4.

External test equipment baudrates

The external test equipment must comply with the mandated OBD/WWH-OBD baud rates, which may differ based on legislation In cases where the relevant legislation does not define specific baud rates, it is recommended to use either 250 kBit/s or 500 kBit/s.

External test equipment CAN bit timing

CAN bit timing parameter values

The CAN bit timing parameters are designated for external test equipment, while OBD/WWH-OBD-compliant vehicles may utilize different parameters to meet their required baud rate Nonetheless, these vehicles must maintain compatibility with the specified external test equipment for effective communication.

The required CAN bit timing parameter settings for external test equipment are defined according to ISO 11898-1, specifically for operation at 250 kBit/s and 500 kBit/s The CAN controller must comply with the protocol specifications of CAN 2.0A (standard format) and CAN 2.0B passive (29-bit ID extended format), ensuring adherence to ISO 11898-1 standards.

The enhanced protocol will support higher clock tolerance, allowing for a 2-bit message intermission, while ensuring that extended frame messages remain undisturbed unless bit errors are detected.

The CAN bit timing parameter values used in this part of ISO 15765-2 are based on equivalent terms in ISO 11898-1:

— tSEG1 = Prop_Seg + Phase_Seg1 = tBIT − tSYNCSEG − tSEG2,

— tBIT = tB (nominal bit time),

— SP = nominal sample point position = (1 − tSEG2/tBIT) × 100 %.

Compliance with the nominal bit time tolerance in ISO 15765 relies on the CAN system clock tolerance of external test equipment and the programmed nominal bit time value In a typical CAN controller, this nominal bit time must be an integer multiple of the system clock periods When the programmed value matches the required nominal bit time, accuracy is influenced solely by the system clock tolerance However, if there is a deviation from the nominal value, accuracy is affected by both this deviation and the system clock tolerance Additionally, the effects of system clock drift or aging, along with the challenges in achieving the desired nominal bit time, are cumulative Therefore, the bit time tolerance specification must account for both factors.

Figure 8 illustrates the partitioning of the CAN bit time.

Figure 8 — Partitioning of CAN bit time

Nominal baudrate 250 kBit/s

Table 10 specifies the allowed CAN bit timing parameter values for a baudrate of 250 kBit/s The external test equipment shall operate in single data sampling mode.

The tolerance of the external test equipment nominal baudrate 250 kBit/s shall be ±0,15 %.

Table 10 — 250 kBit/s CAN bit timing parameter values — Single data sampling mode

Parameter Minimum Nominal Maximum tBIT_RX 3 980 ns 4 000 ns 4 020 ns tBIT_TX 3 994 ns 4 000 ns 4 006 ns tQ — — 250 ns Δf — — 0,15 %

The nominal bit time \$t_{BIT\_RX}\$ for receiving bits from the CAN bus is defined by its minimum and maximum values, which account for a worst-case scenario based on a baud rate tolerance of ±0.5%.

The nominal bit time, denoted as \$t_{BIT\_TX}\$, has defined minimum and maximum values that represent the worst-case scenarios for transmitting bits over the CAN bus These values are determined based on the specified external test equipment's nominal baud rate tolerance of ±0.15%.

Table 11 presents the only allowed CAN bit timing parameter values for the external test equipment based on standard time quanta (tQ) and the timing parameters listed in 12.3.1.

Table 11 — 250 kBit/s CAN bit timing parameter values for standard time quanta tQ ns tSJW ns tSEG1 ns tSEG2 ns

The nominal sample point position is specified relative to one bit time.

Nominal baudrate 500 kBit/s

Table 12 outlines the permissible CAN bit timing parameters for a baud rate of 500 kBit/s, with external test equipment required to function in single data-sampling mode Additionally, the nominal baud rate tolerance for the external test equipment is set at ±0.15%.

Table 12 — 500 kBit/s CAN bit timing parameter values — Single data sampling mode

Parameter Minimum Nominal Maximum tBIT_RX 1 990 ns 2 000 ns 2 010 ns tBIT_TX 1 997 ns 2 000 ns 2 003 ns tQ — — 125 ns Δf — — 0,15 %

The nominal bit time \$t_{BIT\_RX}\$ represents the worst-case minimum and maximum values for receiving bits from the CAN bus, considering a nominal baud rate tolerance of ±0.5%.

The nominal bit time, denoted as \$t_{BIT\_TX}\$, has defined minimum and maximum values that represent the worst-case scenarios for bit transmission on the CAN bus These values are determined based on the nominal baud rate tolerance of the external test equipment, which is set at ±0.15%.

Table 13 presents the only allowed CAN bit timing parameter values for the external test equipment based on standard time quanta (tQ) and the timing parameters listed in 12.3.1.

Table 13 — 500 kBit/s CAN bit timing parameter values for standard time quanta tQ ns tSJW ns tSEG1 ns tSEG2 ns

The nominal sample point position is specified relative to one bit time.

External test equipment

General

The article outlines the essential electrical parameters that external test equipment must meet, distinguishing between the requirements for the CAN interface and the cable of the external test equipment.

NOTE The requirement for cable shielding is specified in 12.4.3.3.

Figure 9 — External test equipment electrical parameters

CAN interface

12.4.2 through 12.4.3 specify the required electrical parameters for the external-test-equipment CAN interface, excluding the cable (see 12.4.3) and the OBD/WWH-OBD connector.

The capacitive load of external test equipment does not account for the load from the connecting cable The specified values pertain solely to the CAN interface of the external test hardware, excluding the a.c termination (refer to section 12.4.2.3.3) These values are observed in the recessive state when the external test equipment is unplugged from the cable and the a.c termination has not been applied (see Table 14).

Table 14 — External test equipment capacitive load — Without cable capacitive load

Parameter Minimum Nominal Maximum pF Description

CCAN_H, CCAN_L — — 100 CAN_H/CAN_L to ground potential

The propagation delay of external test equipment does not account for cable propagation delay and specifically pertains to the CAN interface of the hardware This requirement is crucial for ensuring optimal timing while operating at the mandated OBD/WWH-OBD-compliant baud rate.

The external test equipment's propagation delay, also known as loop delay, encompasses all delays associated with the CAN interface, including those from the CAN transceiver and CAN controller For detailed information, refer to Table 15.

Table 15 — External test equipment propagation delay — Loop delay without cable delay

Parameter Minimum Nominal Maximum ns Description tTOOL — — 390 Loop delay of external test equipment

This subclause specifies the termination requirements to be fulfilled by the external test equipment. Figure 10 illustrates the external test equipment CAN bus a.c termination.

Figure 10 — External test equipment CAN bus a.c termination

Termination resistors must not be placed between the CAN conductors CAN_H and CAN_L in external test equipment to ensure proper adaptation to the physical media impedance The external test equipment should function as an unterminated node on the connected CAN bus.

The external test equipment shall have an a.c termination for the purpose of minimizing reflections on the CAN bus See Table 16.

Reflections on the CAN bus arise in the external test equipment's CAN interface, as the use of a physical media termination resistor for impedance adaptation is not allowed (refer to section 12.4.2.3.2).

Table 16 — External-test-equipment a.c termination parameters

Parameter Minimum Nominal Maximum Description

C1, C2 470 pF 560 pF 640 pF Capacitor of the a.c termination

External test equipment cable

The external test equipment cable shall provide interconnection between the vehicle’s OBD/WWH-OBD connector and the CAN interface of the external test equipment (see 12.4.2).

The length of the external test equipment cable is specified as the distance between the vehicle's OBD/WWH-OBD connector and the CAN interface of the external test equipment (refer to Table 17).

Table 17 — External-test-equipment cable length

Parameter Minimum Nominal Maximum m Description lCABLE — — 5 External test equipment cable length

The cable propagation delay is defined as a one-way delay from the OBD/WWH-OBD connector to the external test equipment CAN interface, and it does not include the propagation delay of the external test equipment This specification is crucial for ensuring accurate timing at the mandated OBD/WWH-OBD-compliant baud rate of 500 kBit/s.

Table 18 — External-test-equipment cable propagation delay

Parameter Minimum Nominal Maximum ns Description tCABLE — — 27.5 External test equipment cable delay

The following configuration requirements apply to the external test equipment cable.

— No other wires shall be twisted with CAN conductor(s) CAN_H or CAN_L However, twisting of the CAN conductors with Signal Ground is allowed.

NOTE There are no further requirements for twisting.

— The CAN_H and CAN_L conductors shall have the same length and traverse the same path for the entire distance.

— CAN_H and CAN_L conductors shall not be included in a bundle containing radiating wires which induce more than 0,5 V noise modulation on either CAN conductor relative to Signal Ground;

When the length of the external test equipment cable exceeds 1 meter, it is essential to use a shielded cable The shield must be connected to the chassis ground pin on the cable side of the OBD/WWH-OBD connector.

[1] ISO 7498-2, Information processing systems — Open Systems Interconnection — Basic Reference

[2] ISO 11898-3, Road vehicles — Controller area network (CAN) — Part 3: Low-speed, fault-tolerant, medium-dependent interface

[3] ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements

[4] ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services

[5] ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)

[6] ISO 15031-2, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 2: Guidance on terms, definitions, abbreviations and acronyms

[7] ISO 15031-3, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 3: Diagnostic connector and related electrical circuits, specification and use

[8] ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 6: Diagnostic trouble code definitions

[9] ISO 15765-1, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) —

Part 1: General information and use case definition

[10] ISO 27145-2, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics

(WWH-OBD) communication requirements — Part 2: Common data dictionary

[11] ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference

Model: The Basic Model — Part 1

[12] ISO/IEC 7498-3, Information technology — Open Systems Interconnection — Basic Reference

Model: Naming and addressing — Part 3

[13] ISO/IEC 7498-4, Information processing systems — Open Systems Interconnection — Basic

Reference Model — Part 4: Management framework

[14] ISO/IEC 10731:1994, Information technology — Open Systems Interconnection — Basic Reference

Model — Conventions for the definition of OSI services

[15] SAE J1930-DA, Digital Annex of Electrical/Electronic Systems Diagnostic Terms, Definitions,

[16] SAE J1939, Recommended Practice for a Serial Control and Communications Vehicle Network

[18] SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes

[19] SAE J2012-DA, Digital Annex of Diagnostic Trouble Code Definitions and Failure Type Byte

Tiêu đề	Tiêu chuẩn iso 15765 4 2016
Trường học	International Organization for Standardization
Chuyên ngành	Standards
Thể loại	tiêu chuẩn
Năm xuất bản	2016
Thành phố	Geneva

Định dạng
Số trang	34
Dung lượng	1,85 MB