Introduction to ISO 15765-2

ISO 15765-2 specifies the network layer communication protocol for data exchange between network nodes (ECU to ECU or Tester to ECU) based on the CAN bus. This protocol is the basis for other more detailed specifications, for example, the UDS diagnostic specification. This standard also specifies the important part of CAN message segmentation: If the data to be sent does not fit into a single CAN frame, a CAN frame segmentation process is performed.

Services to high layers.

ISO 15765-2 defines the service interfaces which defines services that are necessary to access functions that are offered by the network layer (transmission and reception of data, the configuration of protocol parameters).

2 types of services are defined:

Communication services. These services enable data transfer of no more than 4095 bytes. The following services are defined.

  • USData request, is used to request data transfer. If necessary, the network layer will segment the data.
  • USData_FF.indicator. It is used to announce the start of a segmented message reception for the upper layers.
  • USData.Indicator. It is used to give received data to the upper layers.
  • USData.Confirm. It is used to conform to the upper layers that the required service was dispatched (correctly or not).

Protocol parameter configuration service. These services enable the dynamic configuration of specific internal parameters.

  • N_ChangeParameter.request to require a parameter change. –
  • N_ChangeParameter.confirm to indicate to higher layers that a parameter change was made (whether correct or not).

Internal network layer operations

The internal operation of the network layer provides methods of segmentation, flow-controlled transmission, and reassembly of segmented messages. The main purpose of the network layer is to transfer data that may or may not fit into a single CAN frame. Messages that do not fit into a single CAN frame are segmented into several parts and each one is transmitted with a CAN frame that correlates with the other frames of the message.

The image below shows a stream without segmentation

<can1>

The image below shows a stream with segmentation

<can2>

An important CAN message that does not include broadcast data is flow control. Flow control is used to match the sending of data from the “sender” with the data reception capabilities of the “receiver”. This flow control allows the use of diagnostic gateways and sub-networks.

Network layer protocol.

A CAN message can have various interpretations based on the level of service or layer where it is being transmitted or received. At the network layer level, the CAN message is interpreted as a PDU.

The PDU enables the transfer of data between nodes that are within a specific network layer. All PDUs consist of 2 fields along with the data field:

Address Information (N_AI). N_AI is used to identify the entities of the network that are communicating. The N_AI information received in the N_SDU (data set which is sent from the use of services in higher layers of abstraction following the same semantics as PDUs) is copied towards the N_PD. If the data of the N_SDU is very large, then the N_AI is repeated several times in the N_PDUs that make up the message. This field contains the address information which identifies the type of message to be exchanged, the receivers, and the “sender” while the communication takes place.

Protocol Control Information (N_PCI). This field identifies the type of N_PDU to exchange. The N_PCI varies depending on the type of N_PDU and is identified with a PCI ID:

  • SF N_PCI (N_PCItype = 0), consists of the data size (SF_DL) SF_DL is used to specify the number of bytes of service usage data.
  • FF N_PCI (N_PCItype = 1), consists of the data size (FF_DL) FF_DL is used to specify the number of bytes of service usage data.
  • CF N_PCI (N_PCItype = 2), the sequence number (SN) is used to specify the order of the CFs. The SN must start with 0, and the 0 corresponds to the SF, which does not contain an SN but must be treated with an SN of 0. The SN must increase by 1 for each CF that follows in the sequence; if the SN reaches 15 decimal places, it must return to 0.
  • FC N_PCI (N_PCItype = 3), the FC N_PCI is composed of the flow status (FS), and the receiver capacity parameters (BS and STmin). FS is made up of ContinueToSend (CTS) and Wait (WT). CTS should cause the “sender” to resume sending CFs, and WT should cause the “sender” to continue waiting for a new FC N_PDU.

<Can3>

Transmission of individual frames.

Transmission of messages of more than 6 bytes (for extended and combined addressing formats) or seven (in case of normal addressing format) is performed with the transmission of a single N-PDU (Network layer protocol data unit).

Multiple frame transmission

Long message transmission is performed by message segmentation and transmission of multiple N-PDUs and reassembly at the receiver side (concatenation). Multiple N-PDUs are called FirstFrame (for the first N-PDU) and ConsecutiveFrames (for subsequent N-PDUs).

The receiver can adapt the transmission of N-PDUs through the flow control mechanism using the Flow Contro (FC) N-PDU.

The last ConsecutiveFrame will contain the remaining bytes of the message and therefore the data can be smaller than 6 or 7.

<can4>

The size of the message is contained in the FF N-PDU. All CF N-PDUs are numbered by the “sender” to help the “receiver” with the order of the data in the reassembly of the message. The receiver can be configured to behave when receiving a different order of CFs than expected; usually, it is defined that the message is discarded.

Receiver capabilities

The receiver uses flow control to indicate its following capabilities:

  • BlockSize (BS) is the maximum number of N_PDUs that the receiver allows the “sender” to send before waiting for authorization to continue the transmission of other N-PDUs; based on sending a FlowControl.Continue between CFs. The BlockSize is encoded in byte 2 of the FCF N-PCI (network protocol control information). The unit of BS is the absolute number of CFs per block. For example, if BS equals 20 decimal, then the block must consist of 20 CFs. The number of blocksize is then delimited by sending Flow Control frames, at the beginning indicating the acceptance of the first CF to be sent and at the end, it is sent to identify the end of the last CF of a specific BS and the start of a new BS.
  • Minimum Separation Time (STMin) is the minimum time that the sender has to wait between the transmissions of 2 consecutive N-PDUs to avoid saturating the network bandwidth. The unit of STMin is milliseconds, but there can be ranges of STmin that support times in microseconds (transmission as fast as possible). The STMin is encoded in byte 3 of the FCF N-PCI (network protocol control information). This time is specified by the receiver and must be respected by the “sender” during the sending of such a message.

Network layer time parameters.

In some ECU specifications, they require certain time restrictions at the network layer to detect and delimit time faults in the transmission of the CAN message. Some of these parameters entail an internal processing time of the message and others between the bidirectional communication delay between the sender and the receiver. Based on the following image, the time parameters are described; however, always consider that the sender and receiver can change their interpretation based on what type of message is being observed (be it a request or response).

<can6>

  • N_As is the transmission time of any N_PDU from the “sender”.
  • N_Ar is the transmission time of any N_PDU from the receiver.
  • N_Bs is the time until there is a reception of an FCF.
  • N_Bs is the time until there is a transmission of an FCF. (N_Br + N_Ar) <(0.9 * N_Bs timeout)
  • N_Cs is the time until the transmission of the next CF. (N_Cs + N_As) <(0.9 * N_Cr timeout)
  • N_Cr is the time until the reception of the next CF.
Network layer timeouts.
  • N_As timeout happens when any N_PDU was not transmitted in time from the “sender” part. N_Ar timeout happens when any N_PDU was not transmitted in time from the receiver side. N_Bs timeout happens when an FCF is lost on the sender side or when an FF or CF is overwritten on the receiver side. N_Cr timeout occurs when a CF N_PDU is lost (or overwritten) on the receiver side or an FC N_PDU is lost or (overwritten) on the sender side.

Unexpected entry of a PDU.

Depending on the design of the point-to-point communication between 2 nodes to use a half or full duplex, unexpected communication inputs can be interpreted in different ways. Half-duplex communication is possible in only one direction at a certain time; while full-duplex communication allows two-way communication at a certain point. If the communication is half-duplex, and there is a conflict (we are receiving a request when we are transmitting a response) then the behavior will depend on the OEM requirements; the last transport will probably be required to be skipped, or the transport with the highest priority to be processed.

UDS CAN Introduction

Unified Diagnostic Spec (UDS) or for CAN diagnosis (ISO 14229-3) is a group of specifications that specify in detail how the communication of diagnostic messages between a “tester” and an ECU should be. UDS mainly defines the diagnostic services that each ECU must support; along with its subfunctions, and the positive and negative response structures.

CAN diagnostic service communication is based on ISO 15765-2 and can be detailed by specific ECU requirements. The ECU can specify which services to support, in what manner, and what would be its responses to specific diagnostic conditions.

Diagnostic services

A diagnostic service starts with a request from the tester to the ECU, the ECU verifies the validity of the request at the transport protocol level and then routes it to the service validation verification. The validation of the service will check if the service is supported and under what conditions, if the sub-functions of that service are supported, and what the response would be based on the conditions of the ECU and the tester request. The services are identified by an ID (SID) and UDS determines how the request and response of such service should be composed.

The following list specifies which are the UDS services:

  • 0x10 Diagnostic Session Control. Request to be able to switch between different types of sessions. Each session can have different conditions, diagnostic support, and timing requirements.
  • 0x11 ECU Reset. Request to trigger an ECU reset using the tester. A practical method for diagnostic routines that require an ECU reset (programming session transitions).
  • 0x14 Clear Diagnostic Information. Request to clean memory as diagnostic entities (for example DTCs or DIDs).
  • 0x19 Read DTC Information. Request to read extended data of the DTCs in different types of behaviors (request the information employing the DTC number, or DTC range, or DTC mask).
  • 0x22 Read data to identify. Request for DIDs to read different data from the ECU, either something defined in BSW or ASW.
  • 0x23 Read memory by address. Request to read the raw data in a specific, delimited session (if safety or security methods are present) from memory.
  • 0x24 Read escalation data by identifier. Request that allows the client to collect escalation data information from the server through DIDs
  • 0x27 Access to security. Request for security utilities, for example, generation of Seeds, reading of keys, and use of a hash function.
  • 0x28 Communication Control Request that turns the reception or transmission of specific messages on or off.
  • 0x29 Authentication 0x2A Reading of data by periodic identifier.
    Request that allows the client to periodically transmit data recording values ​​from an ECU server.
  • 0x2C Dynamically defined data identifier. Request that allows you to dynamically define a DID that can be read by the 0x22 service.
  • 0x2E Write by data identifier. Request for the tester to write valid data within certain ECU functionality through DIDs.
  • 0x2F Input and output control based on the identifier Request that allows substituting a value of an input signal or forcing the control of an output value of an electrical system.
  • 0x31 Routine check. Request for the execution of predefined routines of the ECU.
  • 0x34 Request to download SW. Request to download SW update binaries (requires at a certain point to enter programming session), this download can be partial or complete.
  • 0x35 Request for SW update. The request used to transfer data from a server ECU to the client ECU
  • 0x36 Data transfer. Data transfer from the server ECU to the client ECU or from the client ECU to the server ECU
  • 0x37 Data transfer output. Request to complete the transfer between the client and the server.
  • 0x38 File transfer request. Transfer of a file from the server ECU to the client ECU or from the client ECU to the server ECU.
  • 0x3E Tester Present. Request that normally does not involve an ECU action other than updating a s3srv timer (timeout to exit to the current session if no request had happened).
  • 0x3D Memory writing by address. Request that allows the client ECU to write to the server in one or more contiguous memory locations.
  • 0x83 Access to time parameters. Request to read or change the default time parameters of a communication link during the time this communication link is active.
  • 0x84 Secure data transmission. The request is to transmit data that must be protected against third-party attacks.
  • 0x85 Configuration of control DTCs. Request that allows to stop or resume updating of DTCs status bits.
  • 0x86 Response per event Request that allows to stop or resume the transmission of responses for a specific condition.
  • 0x87 Link control. Request used to control communication between client ECU and server ECU to gain bus bandwidth for diagnostic purposes.
  • 0x7F negative response SID.
  • Service SID + 0x40 SID for positive response.

Autosar CAN TP

CAN TP (Transport protocol layer) is the module between PduR (top layer) and CANIF (bottom layer). The main purpose of CAN TP is to segment and reassemble CAN I-PDUs (PDUs that come from COM or another module of the upper layer of interaction) based on ISO 15765-2, UDS, among others (based on the system use case). The CanTp module has been designed with diagnostic specifications, but can be handled for the requirements of other CAN-based systems without diagnostic.

CanTp has a connection to PduR. PDUR is a module on top of CanTp and delivers the I-PDUS of COM and DCM within different communication protocols at the Transport Protocol level. The router of these I-PDUs depends on their type housed in their identifier (either CAN, LIN, FlexRay, etc). Also, PduR determines whether a transport protocol is necessary or not. CanTp has interfaces with PDUR to transmit or receive data, these interfaces are called CAN N_SDUs.

CANIF, which is a lower module of CanTp, provides CanTp with mechanisms to access CAN bus channels regardless of their location (either inside or outside the uC). For external CAN controller locations, CANIF extracts the ECU HW schematic and the number of CAN drivers. Because CANTP only handles transport protocol frames (FF, CF, SF, or FCs PDUS) and does so depending on the ID of the N-PDU, the CAN interface has to “forward” from an I-PDU to CanTP or PduR.

CanTp provides services for:

  • Segmentation of data to be transmitted.
  • Reassembly of data to receive.
  • Data flow control.
  • Detection of errors in segmentation sessions.
  • Transmission canceled.
  • Reception canceled.

Data consistency.

To optimize the use of resources of the CAN communication layers, CanTp has limited buffer spaces and depends on the direct transfer of the payload from the higher layer N-PDUs – called N-SDUs (Service Data Units). To ensure data consistency, the upper layers of communication must define:

  • In transmission time (from the transmission request to the transmission confirmation has arrived), the N-SDU payload must remain unchanged.
  • At reception times (from the buffer hosting request to the reception of the hosting request of the next buffer), the N-SDU data access will be blocked.

Configurations for CanTp execution

For CanTp to work correctly at runtime, the following configuration definitions must be integrated:

  • Number of CAN N-SDUs to use-
  • Unique identifiers of each CAN N_SDU.
  • Communication address of each CAN N_SDU (Tx and Rx).
  • Type of communication of each channel (half or full-duplex).
  • Addressing the type of each CAN SDU (physical or functional).
  • Addressing the format of each CAN N-SDU (standard, extended, and combined).
  • Association of each CAN L-SDU identifier with each CAN N_SDU identifier.
  • Minimum size of N-SDU.

Connection Channel

To allow the user to choose that I_PDUs can be received (or sent) simultaneously, each N_SDU will be internally routed through a CanTp connection channel. Because a connection channel is not accessible from the outside, all the information necessary to transmit a specific N-SDU must be linked to an N-SDU ID (connection channel number, timeouts, addressing format, etc).

A connection channel represents an internal path for transmission and reception of N-SDUs during runtimes. It uses its resources, such as internal buffers, timers, or state machines. Therefore, each connection channel is independent of other connection channels. Connection channels are for internal use of CanTp and are not externally accessible. By default, each SDU is statically linked to a connecting channel (except for dynamic channel assignment).

CanTp can handle multiple connections from different N-SDUs simultaneously. However, it cannot handle 2 receptions or 2 transmissions with the same N-SDU ID at the same time.

If a new SF / FF is received on an active N-SDU, the connection is terminated and restarted. If a new transmission request is initiated on an active N-SDU, the request is rejected. If a transmission needs to be started, the current transmission must be terminated using CancelTransmit () APIs.

Autosar PduR


From the ECU point of view, the functions of PduR are to receive and transmit I-PDUs between the transport/interface modules with COM and DCM; as well as being used as a gateway.

PduR is an I-PDU (Interaction Layer Protocol Data Unit) transfer module that sits on top of interface modules and transport modules and housed below COM and DCM. Next to PduR, this I-PDU Multiplexer (I-PduM) provides support for multiplexing I-PDUs. I-PDUs are identified by static IDs. PduR determines the destination of each I-PDU employing a table of IDs. I-PDUs are used for data handling with higher layers of PduR (COM, DCM). The routing that PduR processes, does not change to the PDU, it simply addresses the I_PDU in its destination module. In the case of TP routing, addressing the I-PDU can start before the full PDU is received. PduR has to identify the routing path by combining the ID of the source I-PDU and the ID of the destination I-PDU. These IDs are converted when there is a requested transmission; these IDs cannot be dynamically routed, since static routing is the only one supported.

PduR consists of 2 main parts:

  • PduR routing tables are static router tables describing the router attributes for each I-PDU that must be routed.
  • PduR Engine, the code that performs routing actions, such as routing I-PDUs from source to destination (for example, from PduR_Transmit to CanIf_Transmit.

PduR does not support any mechanism of extraction / conversion of the signal or I-PDU, or of checking the integrity of the data (such as checksums)

Transport routing.

The PduR reception operation must always be completed by an “indicator” function that is executed from a lower transport / interface module. This indication function is executed either in the context of a cyclic (“polling”) function of a communication driver, or in the context of an interrupt.

If the TP segments (N-PDUs) of the source are the same as those of the destination, it is possible to route TP I-PDUs using the interface layer gateway (low-level routing). If this type of routing is used, the source N-PDU will no longer be accessible by the transport layer and will be seen as an I-PDU by PduR.

The low-level routing advantage is implemented directly by the interface layer’s “pointer” function and introduces a minimal amount of latency.

However, there are certain disadvantages with low-level routing, such as:

Loss of transport protocol parameters (such as STmin and BS) due to bursts of I-PDUs queued on the destination bus.

There can be no transport protocol conversion because the structure of the frame and the FC handling must be the same in the destination and the origin.

There can be no forwarding of TP I-PDUs routed to a local DCM for functional rqst.

Buffers and Queues

Diagnostic communication usually does not take place on all parts of the ECU at the same time. Therefore, a TP routing path will not have an explicitly allocated buffer. To reduce the RAM usage that is required for queues, Tx buffers are dynamically allocated based on active TP routing paths and can be reused on other routing paths automatically. If a buffer is dynamically allocated on a routing path, the buffer is reserved exclusively. If all the buffers are busy, it is not possible to do any routing, and PduR will report an invalid buffer value that will be transmitted to the TP module (and that can define an error in development or production).

There can be multiple queue definitions, such as the following:

  • Simple queue, a queue can only be used for communication interface routing paths with a data provision of a triggered transmission.
  • Simple queue with priority, there can be simple buffer queues in which the behavior is giving priority to the last transmission request.
  • FIFO type queues, they are also used with an additional queue depth parameter. Besides that, these types of queues define a subtype called shared FIFO queue that can define various Tx and Rx buffer references (either implicit or explicit).

Functional request routing

ECUs acting as gateways typically include diagnostic services, handling physical and functional address requests that come from external diagnostic tools during development, manufacturing, and service.

Functional addressing rqst messages are a type of broadcast request that must be processed by all ECUs in a communication network.

DCM

DCM provides a set of APIs for diagnostic services. DCM functionality is used by external diagnostic tools during development, manufacturing, and services. DCM ensures diagnostic data flow and handles diagnostic states, especially diagnostic sessions and security states. Also, it determines if the service rqst are supported in the defined sessions. The DCM module is independent of the network protocol. All the specific functionalities of the network (CAN, LIN, FlexRay, etc.) are handled outside of DCM, DCM only communicates with the interfaces of PduR networks.

The DCM module receives a diagnostic message from the PduR module. The DCM module internally processes and checks the diagnostic message. As part of the process, DCM will interact with other BSWs or with ASW through RTE to obtain the required data or execute the commands defined by the rqst. After the process, DCM will collect information and send messages back to PduR.

DCM functionality is based on the following sub-modules:

  • Diagnostic Session Layer (DSL): DSL secures rqst data flow and diagnostic responses; especially diagnostic session and security).
  • Diagnostic Service Dispatcher (DSD): processes a flow of diagnostic data by receiving and transmitting requests or responses from the network and communicating it to the data processor in higher or lower layers.
  • Diagnostic Services Processor (DSP): handles current diagnostic services.

DSL


DSL is the intermediary between DSD and PduR in terms of receiving and sending responses and rqsts.

Additionally DSL supports:

  • The management of security levels, RRCRP response (Rqst Received Correctly, Response Pending), concurrency of TesterPresent and periodic transmissions.
  • The management of session states to keep active sessions that are not by default and manage their transport times.
  • The management of the diagnostic protocol and its resources.
  • The communication mode management (Full, Silent, No communication).

Communication between PduR and DSD, having DSL as an intermediary.

PduR indicates to DSL when there is a new receipt of a new diagnostic request by means of a DcmRxPduId (part of DCM). This is done by calling Dcm_ProvideRxBuffer (), which will never return a buffer smaller than the total size of the diagnostic rqst that has been received.

DSD must ask DSL to transmit responses. These responses are sent through DcmTxPduId which is bound to Dcm through configuration. When the transmission is finished, the Dcm_ProvideTxBuffer () function is called, which at the same time and if the transmission was successful, DSL will forward the transmission confirmation to DSD; in the event of an error, DSD is notified not to attempt to re-transmit.

Support segmented response by collated buffer.

If the Collated Buffer configuration is active, DCM must provide a mechanism to send responses longer than what is configured and house a diagnostic buffer. With collated buffer handling, the ECU is not forced to provide a buffer that is as large as the maximum response span. This strategy is only supported for streaming and is only available for internal DCM implementations.

Tester Present

The functional testerPresent request can be sent by the tester in parallel to other functional or physical rqst, therefore, the present tester must have a dedicated DcmRxPduID and with a separate reception buffer.

When PduR calls Dcm_RxIndicator () with the NTFRSLT_OK parameter with a Present tester request ($ 0x3E 0x80) with the positive response suppressed, the DSL must reset the session timeout timer (S3Server) and not forward this request to the DSD.

DSD

DSD is responsible for checking the validity of an incoming diagnostic request and reviewing the progress of the request execution when triggered by DSL. DSD should only process valid requests and should deny invalid requests.

The following use cases are relevant:

  • Receive a message from request and transmit a positive response.
  • The server receives the request, DSD ensures the validity of the request and it is sent to its appropriate DSP for processing. Upon completion of processing, DSP triggers transmission within the indication function. As soon as an rqst message is received, the DcmPduID is blocked by DSL and during the processing of this rqst, no other rqst of the same protocol type can be received, until the response releases the DcmPduID again.
  • The positive response suppression option is fully performed by DSD.
  • Receive a message from rqst and transmit a negative response.
  • If a diagnostic rqst is not valid or if the rqst cannot be executed in the current session or if any parameter that comes with the rqst returns an error, DSD will deny the rqst process and an NRC will be sent.
  • Segmented response.
  • With the diagnostic protocol, some services exchange large amounts of data, for example, ReadDTCInfo (0x19) or UDS transfer data (0x36). In the conventional method, the internal buffer of the ECU must be long enough to hold the longest data message that has to be transmitted, making the buffer full before transmission. In memory usage care methods, the buffer is partially filled and transmitted. The buffer collating mechanism requires little memory but requires a well-defined reaction time for buffer refilling.

DSP

Upon receiving a function call to process a diagnostic rqst from DSD, DSP will perform the following actions:

  • Analyze the received message.
  • Check the format and if the address of the subfunction is correct. DSD checks the session and function while DSP checks the sub-function. DSP will check the size and structure and return an NRC if it is the case (for example NRC 0x12 when the subfunction is not supported).
  • Acquire data or perform the required function in SWCs, BSW, or internal DCM.
  • Assemble the answer.

Reference

https://www.autosar.org/