Professional Documents
Culture Documents
Justin Dow
V1.00.00 | Released
User Manual MICROSAR Classic
Document Information
Reference Documents
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.
Contents
6 Contact ................................................................................................................................. 23
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
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.
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.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:
1. Client-Server for GetDataLength (async. client with result runnable in LinDiag SWC)
2. Sender Reciever for LinTx
3. Sender Receiver for LinRx
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.
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.
2 Configuration / Implementation
How to read diagnostic information from a LIN slave initiated by an UDS DID read
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)..
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.
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-2 LinTP Message Transmission Sequence (Source: AUTOSAR Specification of LIN Interface)
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.
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.
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.
Cdd_LinTp_CopyRxData implemented to copy data from info pointer each segmented frame
received.
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.
> 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)
6 Contact
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com