You are on page 1of 23

MICROSAR Classic

LIN Diagnostic Communication


User Manual

Justin Dow
V1.00.00 | Released
User Manual MICROSAR Classic

Document Information

Reference Documents

No. Source Title Version


[1] Vector TechnicalReference_Cdd_Communication.pdf as delivered
[2] Vector TechnicalReference_LinIf.pdf as delivered
[3] Vector TechnicalReference_PduR.pdf as delivered

Scope of the Document


This technical reference describes the general aspects of the MICROSAR LIN Tp and
Diagnostic routing handling. The document does not describe BSW module specific
functionality or limitations unless this is essential to understand the overall concept. Module
specific details can be found in the documentation of each BSW module.

Caution
This document gives an overview on product-wide behavior or use-cases. To ensure
correct operation of the product always follow the instructions provided in the technical
references and (additionally for safety projects) the safety manual. The content of these
documents always replaces/overrides the content from this user manual.

© 2023 Vector Informatik GmbH Version 1.00.00 2


based on template version 6.2.0
User Manual MICROSAR Classic

Contents

1 Concept and Overview .......................................................................................................... 5


1.1 CDD Within BSW – No Application Layer Usage ........................................................ 5
1.2 Dcm Interface to SWC With CDD Service for LinTP Control ....................................... 6
1.3 Required Configurations ............................................................................................. 7

2 Configuration / Implementation ............................................................................................ 9


2.1 Configuration in DCM .................................................................................................. 9
2.2 Configuration / Implementation in LinDiag SWC ......................................................... 9
2.3 Configuration / Implementation in LinTP-CDD............................................................. 9
2.3.1 API Implementation ..................................................................................... 9
2.3.2 Timeout handling......................................................................................... 9
2.4 Configuration of BswM .............................................................................................. 10

3 Step by Step Instruction...................................................................................................... 11


3.1 Step 1: Configure DID in Dcm With Asynchronous Data Access. .............................. 11
3.2 Step 2: The Following Modules Are Necessary for LIN Diagnostic ............................ 11
3.3 Step 3: If Schedule Table Change is Needed for LIN Diagnostic Messages it
Can Be Done Automatically: ..................................................................................... 12
3.4 Step 4: Initiate the LIN Diagnostic Communication.................................................... 15
3.5 Step 5: Then You Have to Implement the Cdd_LinTp_CopyTxData and
Cdd_LinTp_CopyRxData Functions at Least. ........................................................... 18

4 Example Cdd code............................................................................................................... 19

5 Hints for integration ............................................................................................................ 21


5.1 Error reporting........................................................................................................... 21

6 Contact ................................................................................................................................. 23

© 2023 Vector Informatik GmbH Version 1.00.00 3


based on template version 6.2.0
User Manual MICROSAR Classic

Illustrations
Figure 1-1 High Level Requirement of LIN Master/Slave Diagnostic Handling ...................... 5
Figure 1-2 BSW-Only CDD Approach - No Application Layer Participation ........................... 6
Figure 1-3 RTE Interface Approach - Sharing Competence Between Application and
BSW-CDDMore specifically focused on the required interface – the
following graphic show the RTE interfaces:.......................................................... 6
Figure 1-4 Software Architecture With Rte Interfaces............................................................ 7
Figure 1-5 Requesting a Lin Schedule From the SWC - Via BswM ....................................... 8
Figure 2-1 Screenshot of TimoutHandling (Lin Master) in LinIf Technical Reference ........... 10
Figure 3-1 Cdd_LinTP PDU Connection Example for Slave Response Connection ............ 12
Figure 4-1 Cdd_LinTp_CopyTxData Example..................................................................... 19
Figure 4-2 Cdd_LinTp_TpTxConfirmation Example ............................................................ 19
Figure 4-3 Cdd_LinTp_StartOfReception Example ............................................................. 19
Figure 4-4 Cdd_LinTp_CopyRxData Example .................................................................... 19
Figure 4-5 Cdd_LinTp_TpRxIndication Example ................................................................. 20
Figure 5-1 Definition of Lin_StatusType Enum .................................................................... 22

© 2023 Vector Informatik GmbH Version 1.00.00 4


based on template version 6.2.0
User Manual MICROSAR Classic

1 Concept and Overview

LIN diagnostic communication works off the LIN protocol handling of communication. Master
ECU acts as Diagnostic Gateway to handle frame scheduler to route communication from
tester on CAN bus or is the requester to LIN slave ECU directly. Since Master controls all
scheduling through LinSm (LIN state manager) the LIN stack needs to switch to diagnostic
schedule table when required which will be described later in the document.
If the LIN slave does not support UDS (Unified Diagnostic Services), the diagnostic requests
from a Tester cannot be re-routed by the LIN master directly since the format of the frame
cannot be processed. Alternatively, it is required to receive the request in the LIN master
(e.g. read DID) and communicate to the LIN slave within the diagnostic service.

Figure 1-1 High Level Requirement of LIN Master/Slave Diagnostic Handling

Mainly this can be achieved by two approaches. One remains in the BSW only, but it is more
project specific. The other approach is reaching up to the Application layer but requires more
modules.
From functionality both approaches are similar. The Diagnostic request from the Tester
reaches the ECU (LIN master) via UDS, which is interpreted by the Dcm (Diagnostic
Communication Manager) module. This – especially for the example of Read Data By ID,
which is addressed in this document – leads to the execution of a service, which can be in
form of a function call, or client server connection.

1.1 CDD Within BSW – No Application Layer Usage


If you do not want the Dcm to call a Server Runnable, which is in the Application layer, you
can select the option to execute a function call. This function needs to be implemented by
you within a CDD, that can be fully below the RTE.
The CDD takes over the diagnostic service handling (e.g. state of diag service), the creation
of the message, the handling for LinTP (transmit, read, write), and required error handling.

© 2023 Vector Informatik GmbH Version 1.00.00 5


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 1-2 BSW-Only CDD Approach - No Application Layer Participation

1.2 Dcm Interface to SWC With CDD Service for LinTP Control
If you prefer a fine granular architecture, which can be (mostly) re-used in another project,
you should select the client server connection. Then Dcm triggers a server runnable in a
SWC, which is itself Client of a LinTP-CDD.
The roles are given as follows…
> SWC – diagnostic service handling (pending, ok, n_ok) → Request Handler
> LinTP-CDD – handling of LinTP (transmit, read, write) → Communication Handler
> Error handling is shared between the two

Figure 1-3 RTE Interface Approach - Sharing Competence Between Application and BSW-CDDMore specifically focused on the
required interface – the following graphic show the RTE interfaces:

© 2023 Vector Informatik GmbH Version 1.00.00 6


based on template version 6.2.0
User Manual MICROSAR Classic

1. Client-Server for GetDataLength (async. client with result runnable in LinDiag SWC)
2. Sender Reciever for LinTx
3. Sender Receiver for LinRx

Figure 1-4 Software Architecture With Rte Interfaces

Caution
PduR_Cdd_LinTp_Transmit() required the PduR related Pdu handle-ID, which
is only available within PduR, but not in LinTP or the Cdd. Additionally, it is not
related to the LinTP NSDUs at all. This ID can be identified in the Routing Path
configuration in PduR.

The callback functions provide a Pdu ID as well, which is the LinTP Rx/Tx
NSDU IDs. These can easily be looked up in the LinTp configuration.

> Therefore, the Pdu ID provided in PduR_Cdd_LinTp_Transmit() is


different than the one, which is set in <Cdd>_CopyTxData(). This
mismatch might be misleading, so you should be aware about this issue.

1.3 Required Configurations


The required LIN Schedule tables are given by the LDF. In the LDF it is not possible to
differentiate between Run Continuous and Run Once. Therefore, this information must be
set manually inside of the BSW configuration.
In most projects there are two Master Request and Slave Response Scheule tables each.
One of them should be configured to be Run Continous, the other one as Run Once.
The Application should request the required Schedule Table - via BswM – depending on the
internal/extern dependencies. BswM is requesting the Lin Schedule switch, if it is possible
according to further rule evaluation results, in LinSM.

© 2023 Vector Informatik GmbH Version 1.00.00 7


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 1-5 Requesting a Lin Schedule From the SWC - Via BswM

If only one (request/response) Diag Schedule Table is available, such mode indication by
the Application is not required. The according schedule table is requested by LinIf and the
switch can be configured in BswM without further interaction of the application (as depicted
in Figure 3-). Enabling/Disabling Pdu groups can be performed in the same action list, which
performs the change of the LIN schedule table.

Reference
Find further information in chapter 3.11.4 Diagnostic Schedule Table Change (LIN
master) in the LinIf Technical Reference. You can find the Technical Reference in the
doc | TechnicalReferences folder of your BSW Package.

© 2023 Vector Informatik GmbH Version 1.00.00 8


based on template version 6.2.0
User Manual MICROSAR Classic

2 Configuration / Implementation

2.1 Configuration in DCM


In DCM only the RTE Ports, e.g. for read DID, are needed, which must be connected to your
CDD or SWC (depending on the solution you selected). No further adaptions are required
in DCM.

2.2 Configuration / Implementation in LinDiag SWC


All ports described in chapter 1.2 need to be implemented. The AUTOSAR Standard
interfaces are well described in the Vector TechRef or AUTOSAR SWS for Dcm and LinIf
(which includes LinTP).

2.3 Configuration / Implementation in LinTP-CDD


2.3.1 API Implementation
The APIs mentioned in chapter 3.5 need to be implemented. They establish the lower layer
connection in order to send/receive the data via LinTP module.
If you decided for the CDD-only option, the APIs and DCM port implementations (see
chapter 2.2) must be inside of the CDD as well.
2.3.2 Timeout handling
For LinTp diagnostic connection the timeout handling is performed by LinTp timouts (shown
in the below screenshot). If a timeout is detected the following measures are taken:
> Communication gets aborted
> PduR gets notified
> Schedule table is switched back to applicative schedule
Since the Diagnostic communication is not handled by COM module, its timeout and error
handling mechanisms cannot be applied in this use-case. Instead, you can use above
measures to detect issues within the CDD. For example, by implementing the following add-
ons:
> Connect the CDD to the LinIf Schedule Requested Statemachine, to detect an
unexpected change of the LIN schedule.
> One unexpected change is: A Diagnostic request, but the schedule changes to
applicative instead of diag response.
> Another unexpected change is: The Diagnostic request was sent successfully. While
waiting for the response (from the LIN slave) the schedule is changed to applicative
before a response was received.
In case a timeout condition occurs, the currently active LinTp connection is aborted, PduR
is accordingly notified and in case of a LIN master node, a schedule table change back to
applicative schedule is triggered.
The following figure visualizes the different phases with active timeout obseration:

© 2023 Vector Informatik GmbH Version 1.00.00 9


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 2-1 Screenshot of TimoutHandling (Lin Master) in LinIf Technical Reference

2.4 Configuration of BswM


If you have multipe schedules for the same use, e.g. differing in the mode ONCE or
CONTINOUS, a rule in BswM must be established, which sets the correct schedule
(Diagnostic schedule).

© 2023 Vector Informatik GmbH Version 1.00.00 10


based on template version 6.2.0
User Manual MICROSAR Classic

3 Step by Step Instruction

How to read diagnostic information from a LIN slave initiated by an UDS DID read

3.1 Step 1: Configure DID in Dcm With Asynchronous Data Access.


Step description: This is needed because we have to wait for answer from Lin slave. Set
/MICROSAR/Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort to
USE_DATA_ASYNCH_*.

Note
This is needed for the approach mentioned in chapter 1.2.

3.2 Step 2: The Following Modules Are Necessary for LIN Diagnostic
Step description: Lin, LinIf, LinSM, LinTp. They are configured more or less automatically
by input file assistant based on the ldf file. While Cdd_LinTp will need connections created
to LinTp PDU’s for proper routing.

Note
Yes, most of them are also shown in the above graphics. (Hint: LinTp is part of LinIf)..

© 2023 Vector Informatik GmbH Version 1.00.00 11


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 3-1 Cdd_LinTP PDU Connection Example for Slave Response Connection

3.3 Step 3: If Schedule Table Change is Needed for LIN Diagnostic Messages it
Can Be Done Automatically:
Step description:set/MICROSAR/LinTp/LinTpGlobalConfig/LinTpChannel
Config/ LinTpScheduleChangeDiag to true and create rules in BswM.

Reference
See sequence diagram 9.6 Transport Protocol message transmission in
AUTOSAR_SWS_LinInterface document.

© 2023 Vector Informatik GmbH Version 1.00.00 12


based on template version 6.2.0
User Manual MICROSAR Classic

Note
As mentioned in chapter 1.3, it is needed to switch to the according schedule. This
switching should be initiated by the application (SWC or CDD – depending on your
concept) and performed by BswM. The full sequence of LinTP message transmission
is shown in the following sequence diagram of LinIF AUTOSAR SWS.

Figure 3-3 LinTp Schedule Change Diag Setting

© 2023 Vector Informatik GmbH Version 1.00.00 13


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 3-2 LinTP Message Transmission Sequence (Source: AUTOSAR Specification of LIN Interface)

© 2023 Vector Informatik GmbH Version 1.00.00 14


based on template version 6.2.0
User Manual MICROSAR Classic

3.4 Step 4: Initiate the LIN Diagnostic Communication


Step description: To initiate the Lin diagnostic communication call the
PduR_Cdd_LinTpTransmit function from the DID ReadData (or ReadLength) runnable.

Reference
See 9.2.5 Multicast transmission of I-PDU on transport protocol modules in the
AUTOSAR_SWS_PDURouter document.

Note
There should be a better separation between Dcm, SWC, and Cdd. The Cdd’s Tp
Transmit function should not be called within the Dcm service call. Please follow the
description mentioned in chapter 1.2.

Below example code from sender receiver port connection. Pending needs to be returned
till slave responds with DID content.

Figure 3-4 DCM DID Port Definition Example

Below example code to setup transmission through Pdur_Cdd_TpTransmit. Length is only


used here however data is provided as well for consistency.

© 2023 Vector Informatik GmbH Version 1.00.00 15


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 3-5 PduR_Cdd_LinTpTransmit Setup of Transmit Content

For PduR_Cdd_LinTpTransmit the input variable id that needs to be provided needs to be


the source pdu handle id of the connection you’re trying to setup. This will match up to the
defined slave pdu referenced in Cdd_LinTp that matches to the slave you want to send
service request to. In this example below using Slave1 for the source pdu for the Id.

Figure 3-6 PduR destination reference

There are definitions generated in PduR_Cfg.h that will be used in this case. Best method
is to search for the name of the container of the above reference to find the generated define.

© 2023 Vector Informatik GmbH Version 1.00.00 16


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 3-7 PduR Destination Reference Code

© 2023 Vector Informatik GmbH Version 1.00.00 17


based on template version 6.2.0
User Manual MICROSAR Classic

3.5 Step 5: Then You Have to Implement the Cdd_LinTp_CopyTxData and


Cdd_LinTp_CopyRxData Functions at Least.
Step description: In these functions copy the sent/received data. The info->SduDataPtr
contains the data bytes without NAD and PCI.

Reference
The APIs, which are required to be implemented in the Cdd, are also described in the
Technical Reference MICROSAR Complex Device Driver (named
TechnicalReference_Cdd_Communication.pdf) in the doc folder of your
BSW Package.

Figure 3-8 Screenshot of MSR Cdd Technical Reference Document

© 2023 Vector Informatik GmbH Version 1.00.00 18


based on template version 6.2.0
User Manual MICROSAR Classic

4 Example Cdd code

Cdd_LinTp_CopyTxData needs to be implemented to provide the data to be transmitted


copied from internal buffer.

Figure 4-1 Cdd_LinTp_CopyTxData Example

Cdd_LinTp_TpTxConfirmation can be used to confirm if transmission of segmented frame


has been completed or if error handling is required.

Figure 4-2 Cdd_LinTp_TpTxConfirmation Example

Cdd_LinTp_StartOfReception is needed to handle later on during copy to know length of


data and notify start of data reception from slave.

Figure 4-3 Cdd_LinTp_StartOfReception Example

Cdd_LinTp_CopyRxData implemented to copy data from info pointer each segmented frame
received.

Figure 4-4 Cdd_LinTp_CopyRxData Example

Cdd_LinTp_TpRxIndication is called once all segmented frames have been received. This
is the last point to store the length content of the frame.

© 2023 Vector Informatik GmbH Version 1.00.00 19


based on template version 6.2.0
User Manual MICROSAR Classic

Figure 4-5 Cdd_LinTp_TpRxIndication Example

© 2023 Vector Informatik GmbH Version 1.00.00 20


based on template version 6.2.0
User Manual MICROSAR Classic

5 Hints for integration

5.1 Error reporting


Error handling: how can I know if no answer from LIN slave? My experience is that the result
parameter of the Cdd_LinTp_TpRxIndication and Cdd_LinTp_TpTxConfirmation
functions is always 0.
> If on Sender side TxConfirmation get called, transmission was successful (same for
RxInidcaiton, which shows that data was received – on receiver side)
> For more information about Timeout handling please see chapter 2.3.2.
> Appl_LinIfGetLinStatus() to get the LIN status for the last transmission

© 2023 Vector Informatik GmbH Version 1.00.00 21


based on template version 6.2.0
User Manual MICROSAR Classic

> It is called after each sent Lin frame – and must be enabled by a define (see LinIf
TechRef in the Doc folder of your SIP)

Figure 5-1 Definition of Lin_StatusType Enum

© 2023 Vector Informatik GmbH Version 1.00.00 22


based on template version 6.2.0
User Manual MICROSAR Classic

6 Contact

Visit our website for more information on

> News
> Products
> Demo software
> Support
> Training data
> Addresses

www.vector.com

© 2023 Vector Informatik GmbH Version 1.00.00 23


based on template version 6.2.0

You might also like