Diagnostic Communication Manager

8 Comments / AUTOSAR Com Stack, AUTOSAR Diagnostics / By Alpha

Diagnostic Communication Manager (DCM)

Translate in your language

Background:

As per Murphy’s Law, if anything that can go wrong, will go wrong! 🙂 So considering this, we have to prepare for problematic situations while developing any ECU software because things can go wrong. In general embedded systems programming, we use UART or any serial interface to send or receive debug messages or information of the live or running code on hardware. But we need to implement that functionality by writing a separate code to perform the operation of receiving and transmitting debug messages from UART or serial interface. If we use RTOS, we can also get information related OS on serial interface like UART which is apart from application information. Some sophisticated applications have services which implements service sessions which are grouped by user access role and security in such debug or diagnostic communications. Such applications implement these Diagnostic services to allow tester, or diagnostic engineer to get information from ECU regarding error occurred, or status or general information. These services are used by external diagnostic tools which sends diagnostic request to ECU and ECU replies with desired information.

Since AUTOSAR aims in standardizing software development of ECU, almost each component is standardized in it, hence Diagnostics is no exception. AUTOSAR has Diagnostic Communication Manager (DCM) as the name suggests, is a part of communication services which is used in providing Diagnostic services.

The reader is expected to have knowledge of UDS and OBD protocol before proceeding further.

DCM in detail:

Diagnostic Communication Manager (DCM) is a basic software (BSW) module which is also a part of Com Stack and lies in Communication Services block, provides the functionality to handle diagnostic requests from external diagnostic tool. AUTOSAR DCM supports standard diagnostic protocols like UDS – ISO14229-1, OBD – ISO15031-5 over CAN, FlexRay and MOST bus. DCM module provides common APIs for diagnostic services, this functionality may be used during development or manufacture or service and maintenance of vehicle. DCM module is responsible for ensuring diagnostic data (messages) flow and managing diagnostic states, especially diagnostic sessions and security states.

Above figure depicts the location of DCM in AUTOSAR Com Stack and its a generic block or network independent block which is instantiated only once. All network (CAN, FlexRay, MOST) specific operations are carried out in network dependent blocks. DCM is above PDU router (PduR) and it receives diagnostic request message from PduR. The DCM module processes this message and checks if it is supported. If it is supported, then DCM communicates with BSW modules or SWCs via RTE to get information if required or execute commands to satisfy the received diagnostic request. After gathering the information required, DCM assembles the reply message and sends it via PduR.

Typically, the client has to send diagnostic request messages to ECU (DCM) using a special diagnostic tool which understands UDS or OBD protocol. Diagnostics are used during manufacturing, during service (Its obvious! 😀 ), or during development. Figure below gives pictorial overview of diagnostic with AUTOSAR based ECU.

Sub-modules of DCM:

The DCM module is further divided in sub modules like:

Diagnostic Session Layer (DSL): DSL sub-module is responsible for ensuring smooth data flow of diagnostic requests and responses. Diagnostic protocols have strict timing requirements for perfect communication, DSL also guarantees to achieve such timing requirements. Diagnostic protocol like UDS has diagnostic sessions and states which allows controlling access to information and requests grouping, DSL also handles this work.
Diagnostic Service Dispatcher (DSD): DSD sub-module as the name suggests, acts like a dispatcher whose work is to forward received diagnostic requests to Diagnostic Service Processor (DSP) and forward diagnostic responses received from DSP to DSL for transmitting it over network.
Diagnostic Service Processor (DSP): DSP sub-module is the main part of DCM where diagnostic requests are processed and actions are taken on the requests as needed and a response is generated. DSP get diagnostic request message from DSD and DSP transmits the response to DSD.

Lets understand each sub-module in detail:

Before going any further first lets understand some terms of UDS

1.Diagnostic Services:

Diagnostic services are services given in UDS protocol which the DCM module has to support. These services are nothing but diagnostic requests sent by diagnostic tool to get some information or status or do some setting. Each service is denoted by service ID and while requesting information for a specific service, we have to pass the Service ID (SID) from diagnostic tool.

2.Diagnostic Session:

Diagnostic session is a term used in UDS to indicate a activity window based on time dedicated to perform diagnostic activity with ECU. Types of diagnostic sessions are:

Default Diagnostic Session
Programming Session
Extended Diagnostic Session.
Safety System Diagnostic Session.

Every session supports a specific type of diagnostic service. On startup, default diagnostic session is active and different sessions can be accessed as and when requested by diagnostic tool. Some services are available under Default Diagnostic Session or some which can be used to program ECU are available under Programming Session. Now lets continue with understanding sub modules of DCM.

1. Diagnostic Session Layer (DSL):

DSL sub-module is developed in conformance with ISO 14229-1 [9] and ISO 15765-3 [12], hence its implementation is completely network or bus independent. DSL module helps in session handling, taking care of accurate timings as required by protocol, and managing security. DSL interacts with different other modules to achieve its tasks, modules like:

PduR: DSL module receives diagnostic requests from PduR and DSL module sends the response for the diagnostic request to PduR
DSD sub-module: DSL sub-module informs DSD of incoming diagnostic requests and provides the data. DSL also receives response for diagnostic request from DSD which it forwards to PduR further.
SWCs or DSP submodule: DSL module provides access to security and session state.
ComM module: DSL sub-module has to take care of accurate communication timings, it achieves it with the help of ComM.

Lets study in detail functionalities provided by DSL:

Forward requests from PduR to DSD module: Diagnostics have their own PDUs (for both TX and RX) with their own unique PDU ID, whenever a new diagnostic request reception starts on any of the diagnostic PDU, PduR indicates this to DCM. PduR communicates this information to DSL sub-module which is further forwarded to DSD (Diagnostic Service Dispatcher). PduR requests the buffer to be filled with diagnostic request from DCM module using API: Dcm_ProvideRXBuffer() ,PduR also provides the number of bytes expected to be received This API never returns the filled buffer until its fully filled with expected amount of bytes. After complete reception of diagnostic request (successful or with errors), PduR module calls the Dcm_RxIndication() API to give a receive indication to DCM. After completely reception of request from PduR, DSL blocks this DCM PDU ID (received PDU ID) and new requests from same protocol type, for instance if a UDS type session is going on, new requests of UDS cannot be received.
Concurrent “TesterPresent”: The DCM automatically resets the ongoing diagnostic session and enters into default session if no exchange of data is taken place between DCM and Tester tool for a specific period. To resolve this, ISO14229-1[9] implements a “keep alive logic” which is a service implemented in UDS called as TesterPresent, client (tester tool) sends this request to DCM to indicate client is still present. DCM don’t send any response for this request as its use is to just indicate that client is present. DSL also don’t forward this to DSD as there is nothing of interest in this request.
Forward responses from DSD to PduR: DCM sends its response to tool in a dedicated TX PDU with unique PDU ID via PduR. DSP (sub-module of DCM) sends this response to DSD which is further forwarded to DSL and lastly DSL forwards this to PduR. The request and response PDU IDs are linked with each other during DCM configuration, this guarantees correct response to request received. The DSL module forwards the response PDU to PduR only after the minimum specified delay between request reception and response. DSL uses PduR_DcmTransmit() to indicate length information of response PDU to PduR. After reception of this information, PduR module calls Dcm_ProvideTXBuffer() to request DCM module for the response PDU to be transmitted.
Guarantee timing to tester by sending busy responses: Many times the diagnostic request takes more time for processing, in that case if there is no communication from server (DCM) to tester tool for specified maximum response time, it may think the ECU is not responding and end diagnostic session. To resolve this, DSL sends busy responses to tester tool periodically until the request processing is not completed. The busy response is a negative response (protocol) with NRC (Negative response code) 0x78 which means Response pending. DSL uses a separate buffer to send such busy responses. But this may lead to deadlock 😀 , so to avoid deadlock, during configuration integrator can set the maximum busy responses by setting DcmDslDiagRespMaxNumRespPend configuration parameter. If the number of busy responses if greater than this parameter, DCM module stops the processing of that request and sends the negative response NRC 0x10 which indicates General Reject.
Support of periodic transmission: The UDS has a service to let tester request periodic transmission of data record values from ECU. DSL module handles this request in two ways: 1. If any request processing is going on and using the same PDU ID which is to be used for periodic transmission, DSL would allow such requests only after completing the processing of ongoing request; 2. Or if configured to use separate PDU ID and protocol, the DSL allows this request and sends on separate PDU (which is not used for normal diagnostic requests).
Support for ROE transmission: The UDS has a service named ResponseOnEvent (0x86) using which the tester can request the ECU to start and stop transmission of responses initiated by a specified event. When registering transmission based on event, the tester has to specify the corresponding service to which response is to be sent.
Support of segmented response: When there is a need to send responses that are greater than configured and allocated diagnostic buffer, DSL can segment the response data in pieces and sends the response. With this, the ECU can save memory because there won’t be any need to allocate big buffers for big responses. This segmentation is supported on in sending responses, i.e. segmented requests are not supported by DSL.
Support of ResponsePending response triggered by the Application (SWC): In some cases, the application needs to send immediate ResponsePending responses unlike above described functionality for sending busy responses in which the DSL waits for the minimum time between request and response. This can be used in flash programming scenario, application will send ResponsePending before entering into bootloader.
Manage Security Level: DSL sub-module provides interfaces to get current security level and also to sent new security level. DSL module also saves the current active security level. During DCM initialization, the security level is set to 0x00 this means ECU is locked for that period !
Manage session state: DSL provides interfaces to get current active session and also to set a new session. During DCM initialization, the session state is “Default Session”. DSL module saves the state of current active session.
Keep track of non-default sessions: Whenever a non-default session is going on and the session timeout occurs without receiving any diagnostic request, DSL module resets the current session and enters into default session.
Informs depending modules of session change: Whenever a session change occurs, DSL notifies the corresponding module involved in that session regarding the session change.
Allow to modify timings: As DSL is the one to take care of timing requirements of protocol, it allows to modify timings of session layer as the protocol related timing parameters has no influence on Transport layer. To modify timings of protocol, UDS has defined following services: UDS Service DiagnosticSessionControl (0x10) and UDS Service AccessTimingParameter (0x83).
Handling of different diagnostic protocols: DCM as said in introduction, supports different diagnostic protocols like UDS or OBD, etc. DSL sub module handles this.

2. Diagnostic Session Dispatcher (DSD):

The DSD sub-module is responsible for checking the validity of an incoming diagnostic request. Validity here means verification of Diagnostic Session or Security Access levels or Application permission. This validation helps in processing only valid requests and rejecting invalid requests . DSD sub-module also keeps track of ongoing diagnostic request processing. DSD sub-module interacts with other sub-modules as followed:

- DSL: DSL calls the DSD sub-module when received a new diagnostic request message. DSD then forwards this request to DSP and keeps track of ongoing request processing. It also transmits the response of DSP to DSL. DSD sub-module also calls DSL to get latest diagnostic session and security state. DSD module also get the confirmation of transmission response message from DSL.
- DSP: DSD delegates the received diagnostic request (if valid) and also sends confirmation of transmission of response message to DSP. DSP module sends signal to DSD after processing of diagnostic request is done.

Lets understand the functionalities provided by DSD sub-module:

Support checking the diagnostic service identifier and adapting the diagnostic message: DSD validates the received diagnostic request message from DSL and if supported it is forwarded to appropriate DSP or else it is rejected by sending negative response. Every diagnostic request has a Service Identifier(SID) to indicate the type of request. DSD has the Service Identifier Table which has predefined supported SIDs, this table is generated after configuration and is provided by DSL. DSD checks this received SID from request in the Service Identifier Table and if received SID is present in the table, it is forwarded to appropriate DSP or else it is rejected by a negative response with NRC 0x11 i.e. Service not supported to the DSL.
Handling of suppression of positive response message: UDS has a facility to suppress the positive response message reception on each successful procession of diagnostic request. This is handled by DSD. DSD checks if bit named “suppressPosRspMsgIndicationBit” in received diagnostic request is TRUE, if it is then DSD won’t send positive responses. This setting will be ignored if the busy responses is going on (refer DSL for more information on busy messages).
Verification functionality: DSD sub-module is also responsible for verifying the received diagnostic request. DSD sub-module will only accept the diagnostic request if it passes three verifications:
- Verification of Diagnostic Session: As discussed above, a diagnostic session is a activity window to perform diagnostics. Every session has a specific set of supported diagnostic services. On reception of a new diagnostic request, DSD will get the current diagnostic session information and will verify if the current received service request is allowed for current session. UDS service for DiagnosticSessionControl (0x10) is bypassed of this verification, or else the tester won’t be able to change the diagnostic session then 😀 ! If the received service request is not allowed in current diagnostic session, then DSD sends a negative response with NRC (0x7F) which means Service is not supported for active session.
- Verification of service security access levels: Some diagnostic services have restricted security access levels. DSD sub-module takes care of verification of such services. When a new diagnostic request is received from DSL, DSD gets the current active security level from DSL and checks if the new diagnostic request is allowed for current security access level. If the received diagnostic request is not allowed in the current security level, then DSD sub-module sends a negative response with NRC (0x33). Again UDS service SecurityAccess (0x27) is bypassed this verification, or else the tester will never be able to access security restricted data 😀 ! If the received service request is not allowed for current security level, then DSD sends negative response with NRC 0x33 which means Security access denied.
- Verification of the application environment or permission: Diagnostic cannot be performed if ECU state is not proper or if environment is not appropriate. Like in after-run ECU state, it is not allowed to process OBD requests.
Distribution of diagnostic message to DSP: If the diagnostic service passes all the checks (as described above), then DSD searches for a appropriate service executable functionality of DSP and calls the corresponding DSP service interpreter.
Assemble of positive or negative response: DSD sub-module assembles the response for executed diagnostic request based on the response of DSP. If response is positive, DSD sub-module adds the response service identifier (same as that of the received diagnostic request SID) and response data (which is received from DSP) in the response message while assembling. Or if the response is negative, then DSD assembles a negative response message with NRC received from DSP.
Initiate Transmission: DSD sub-module forwards the response message to DSL sub-module for further transmission. When the DSL module receives the confirmation of transmission from PduR, it transmits this information to DSD. Which the DSD sub-module further forwards to DSP for its confirmation.

3. Diagnostic Service Processor (DSP):

DSP sub-module is the main module which processes the received diagnostic request from DSD sub-module. Upon reception of function call from DSD sub-module to process a diagnostic request, DSP analyzes the received request message, checks its format, checks if the requested sub function is supported, acquire necessary data from DEM, SWCs, or BSW modules, and lastly assemble response.

Lets understand some steps:

Check format and subfunction support: The DSP module checks if the received request has appropriate message length and structure before processing the request. If the requested diagnostic message fails in format checking then DSP module triggers a negative response with NRC 0x13 to DSD. DSP module also checks whether a specific sub-function is supported before executing the service request. If its not supported, then DSP module triggers a negative response with NRC 0x12 to DSD sub-module.
Assemble response: After processing the request, the DSP module assembles the response message (positive/negative) to be sent to DSD. The message is assembled without service identifier (because this is handled by DSD). DSP module confirms the completion of request processing to DSD.

In this way, DCM works with its internal sub-modules like : DSL, DSD and DSP to perform diagnostics communication. DCM is more deep topic and has scope for understanding each supported diagnostic protocol, but for the sake of simplification, I have compiled DCM in most possible simple to understand way.

I hope you understood DCM by reading this article. If you have any doubts or comments please let me know in comments.

If you find any incorrect information please report it to me.

Thanks for reading 🙂 !

Like us on Facebook!

Subscribe for newsletters!

Diagnostic Log and Trace

2 Comments / AUTOSAR Com Stack, AUTOSAR Diagnostics / By Alpha

Diagnostic Log and Trace (Dlt)

Translate in your language

Background:

In general embedded systems programming, we use UART or any serial interface to send or receive debug messages or information of the live or running code on hardware. But we need to implement that functionality by writing a separate code to perform the operation of receiving and transmitting debug messages from UART or serial interface. If we use RTOS, we can also get information related OS on serial interface like UART which is apart from application information.

Similarly, AUTOSAR has a dedicated module in layered architecture to perform the same work of transmission of debug/diagnostic information messages via UART or serial interface or CDD (Complex device driver) and reception of Dlt commands from a external Log tool. Such debug information can be sent from Application (SWC), DEM (Diagnostic Event Manager), DET (Default Error Tracer) and RTE. Dlt module further sends this received information to DCM or CDD or Debug Interface (serial interface) to transmit this to developer/tester.

Dlt module in detail:

Dlt is a basic software (BSW) module which is also a part of Com Stack, provides the facility of Logging and Tracing for SWCs, DET, DEM and RTE. Dlt module is located above PduR and below RTE. Tracing here means VFB trace which has all the information of data exchanges for a SWC via ports. Dlt Module performs following functionalities:

Logging: This functionality involves logging of errors,warnings and info messages from SWCs via standardized AUTOSAR interface, gather all log and trace messages from SWCs in a centralized service component in BSW, log messages from DET or DEM.
Tracing: This functionality is useful for logging the RTE or VFB trace.
Control: Dlt also handles some control functionalities like enable/disable log messages or control trace levels individually by configuration using a specialized tool.
Generic: Generic functionalities like: Dlt module is available during debugging and production phase, Dlt is accessible using a standard diagnosis or platform interface, Dlt module also provides security mechanisms to prevent misuse in production phase.

Dlt receives information like: state of application from SWC, or log message, development errors from Default Error Tracer [DET] (which is responsible for tracking errors in BSW occurring during development in runtime), diagnostic messages from Diagnostic Event Manager [DEM] (which is responsible in managing the diagnostic messages having diagnostic information like Freeze frame,Diagnostic trouble codes [DTC]). Dlt further converts this information in a standard Dlt format which follows the Dlt protocol (as given in figure below) and passes this information to Pdur for further sending it on communication bus. Dlt provides APIs which are accessed by above listed modules for transmitting information to Dlt.

Diagnostic Log and Trace protocol:

Information (log message) sent by SWC or other modules cannot be sent directly on communication bus, as it will contradict the aim of AUTOSAR to standardize communication. Before sending the message on communication bus, Dlt converts the message and modifies it in a standard message by following protocol which has specific format, message sequences and semantics of protocol called Dlt Protocol. Dlt protocol allows external logging tool to communicate with Dlt (using standard Dlt commands) for setting filter on log messages to be received based on severity level (fatal error, information, or warning). External logging tool can also in runtime inform SWCs to generate only logs matching filter level, or change the communication bus on which the message is to be sent, or store filter level configuration in non-volatile memory to avoid configuring Dlt again. Lets study what that protocol is.

Above figure (Fig.2.1) is Dlt message format as per protocol and figures 2.2,2.3 are expanded headers of the Dlt message, Dlt message has three parts:

Standard Header: As shown in Fig.2.2, It is a 16 byte header which consists of fields like: header type (contains general information about Dlt message which indicates which fields in standard header are present or not and also indicates if extended header is used), 8-bit Message Counter (this is counter to count Dlt messages received by Dlt module), Length (16-bit length of message), Optional ECU ID (It is used to identify which ECU has sent Dlt message), Optional Session ID (it is used to identify the transmitter of a log or trace message within a ECU), Optional Timestamp (it is used to add timing information a Dlt message has been generated)
Extended Header: As shown in fig 2.3, It is a 9 byte header which consists of following fields: Message Info (It contains information of Verbose or non Verbose message, Type of message [Log message,Trace message,Network message,Control Message], Message Type info [which is dependent on Type of message] for instance, if type of message is Log, then this field indicates different types of Log messages like Fatal, Error, Info, Warning,Debug, Verbose),Number of Arguments (It indicates the number of arguments in the payload of Dlt message),Application ID (It is a abbreviation of SWC which generates the Dlt message), Context ID (It is user defined ID to logically group Dlt messages generated by a SWC).
Payload: This contains the parameters that are logged or traced or it can also have control information. In verbose mode, this will have meta-data which indicates the type information of payload like: boolean,Raw,String,Variable, Fixed point, etc. But in non verbose mode, this information has to be constructed as meta-data is not transmitted in it.

Dlt communicates with external logging tool asynchronously without any external stimulation or connection request as we do in TCP. Applications (SWCs) can register for receiving notifications from Dlt to get notified about filter setting changes done by logging tool. Application can send log message in verbose or non-verbose mode. In verbose mode, meta-data is added with log message which is useful for the logging tool to interpret log messages and help the tester. In non-verbose mode, no meta-data is sent with log message instead a separate FIBEX file is used which has all the meta data which the logging tool uses to interpret messages.

Services/Commands supported by Dlt:

Service ID	Dlt Command Name	Description
0x01	SetLogLevel	Set the Log Level
0x02	SetTraceStatus	Enable/Disable Trace Messages
0x03	GetLogInfo	Returns the LogLevel for registered applications
0x04	GetDefaultLogLevel	Returns the LogLevel for wildcards
0x05	StoreConfiguration	Stores the current configuration non volatile
0x06	RestoreToFactoryDefault	Sets the configuration back to default
0x0A	SetMessageFiltering	Enable/Disable message filtering
0x11	SetDefaultLogLevel	Sets the LogLevel for wildcards
0x12	SetDefaultTraceStatus	Enable/Disable TraceMessages for wildcards
0x13	GetSoftwareVersion	Get the ECU software version
0x15	GetDefaultTraceStatus	Get the current TraceLevel for wildcards
0x17	GetLogChannelNames	Returns the LogChannel’s name
0x1F	GetTraceStatus	Returns the current TraceStatus
0x20	SetLogChannelAssignment	Adds/ Removes the given LogChannel as output path
0x21	SetLogChannelThreshold	Sets the filter threshold for the given LogChanne
0x22	GetLogChannelThreshold	Returns the current LogLevel for a given LogChannel
0x23	BufferOverflowNotification	Report that a buffer overflow occurred

Above table lists down the supported services/commands by Dlt module which are to be used while sending commands from external logging tool. I won’t be going in detail explaining each command, because it will make this article lengthy 🙂 .

Communication of Dlt with other layers/modules:

1. Communication with application layer (SWC):

SWCs can communicate with Dlt in two ways:

Using Dlt interfaces to send Log and Trace messages
Using a port provided by Dlt to get notifications on changes in log threshold level and trace state by logging tool. This will only generate Log or Trace messages of interest.

As discussed above, Dlt module uses a tuple of Application ID/Context ID to identify messages but Dlt module also supports multiple instances of SWCs (in AUTOSAR SWC can have multiple instantiation, so messages can be generated by each instance of SWC and Dlt supports it) which use same tuple of Application ID/Context ID, to differentiate between multiple instances of messages from same SWC, a new field is also added with that tuple named Session ID. But this again makes the problem more complex 😀 , so Dlt provides a dedicated provider port for each configured SWC instance which acts as a Session ID in port defined argument for the provider port. The assignment or non assignment of tuple of Application ID/Context ID to respective SWC can be done during configuration or runtime with a call to RegisterContext and UnregisterContext respectively.

2. Communication with RTE for VFB Trace:

As discussed in beginning of this article, Dlt module can get VFB trace from RTE which has information of Data exchanges between SWC and RTE without any information to SWC. To allow Dlt to record VFB trace, this has to be configured during RTE configuration with “Dlt” in configuration parameter RteVfbTraceClientPrefix. This configuration generates VFB Trace hook function which is implemented in Dlt module which uses interfaces provided by RTE.

3. Communication with DEM:

DEM stores the events and event ID of events generated by SWCs and BSW modules. Every event has Diagnostic Trouble Code (DTC), Extended Data Records, and a Freeze Frame, we will discuss these terms in more detail in Diagnostics related article. DEM communicates with Dlt by calling Dlt’s Dlt_DemTriggerOnEventStatus function on each change in state of event to notify Dlt of this change. While calling this function, DEM provides EventID of event. Dlt uses this EventID to get more information about the event. In this function, Dlt module compares the old status with new status of event, if there is change in status of event, then Dlt builds a Dlt log messages with new status and sends it.

4. Communication with DET:

DET module is responsible for reception of reporting of errors from SWCs and BSW modules. Such errors are forwarded to Dlt module as message with suitable content using the API Dlt_DetForwardErrorTrace. The log level for DET errors is “Error”.

4. Communication with NVM:

As discussed above, Dlt can store the filter configuration persistently by storing it in non volatile memory. For this, Dlt module has to talk with NVM module. The command to be used by logging tool (from above shared table) is StoreConfiguration with service ID 0x05.

Transmission of Log and Trace messages from Dlt:

Above figure depicts the path of Log message transmission from SWC to lower layers.

Note: I have combined some blocks for simplification so this figure may not match with original AUTOSAR figure, but the gist is same.

The steps as per above figure are:

Generate timestamp: If configured, timestamp will be added to the message.
Filter message: Message filtering means to accept or discard an incoming log or trace message based on the Application ID/Context ID tuple, which is assigned to that message. Here messages with log level as configured in filter are only passed others are discarded.
Select target LogChannel: Dlt module in this step, selects the target channel as per configuration for log message.
Check Message length and apply the current LogChannel threshold: Dlt module can be configured to only pass a maximum size of message, if configured then it enforces it in this step and discards all the log messages which are large in size. This step also check if the Log level threshold (check commands table) matches with configured level for selected channel, if not then the log message will be discarded.
Copy Dlt message to LogChannel specific buffer: In this step, Dlt module copies the message (if passed in above steps) to the buffer of selected channel.

Further the Dlt message is passed to PduR and is passed on to respective handles.

Here ends this article! I hope I explained it in easy language and you understood it.

Please let me know your doubts in comment box. If you find any incorrect information, please report it. I will highly appreciate if you will subscribe for newsletters from below!

Thanks for reading 🙂

Like us on Facebook!

Subscribe for newsletters!

Generic Network Interface

4 Comments / AUTOSAR Com Stack / By Alpha

Generic Network Management Interface

Translate in your language

We already covered the generic blocks of Communication services in brief in my other article, now I will be explaining each block of it in detail, this article will focus on Generic Network management interface block. The Generic Network Management Interface(NM) is a part of generic blocks of Communication Services block of AUTOSAR Layered Architecture. It is a adaptation layer between the AUTOSAR Communication Manager(ComM) and bus specific or network dependent network management(NM) block of Bus (for e.g.: CanNm for CAN bus). It handles the task of changing network states from awake to sleep to save power.

Note: Please don’t confuse the Generic Network management module with Bus specific network management module while reading further. 🙂

Above figure is the Com Stack with only Generic Network Management block highlighted. This is a network independent block hence it is instantiated only once and reused again for all buses i.e. there won’t be different blocks for CAN Bus and FlexRay Bus, instead same NM block will be used for both buses. Generic NM provides a interface for Communication manager(ComM) and uses services offered by bus specific NM modules like CanNm. ComM communicates with bus specific NM module via Generic NM module thereby achieving complete abstraction and hardware(bus) independence.

Some features of Generic Network Management module:

Generic NM allows adhoc addition of new nodes seamlessly, just that node should have “NmSelectiveNmChannel” property set to False during configuration. Such newly added nodes can be of types like: nodes which connected late, nodes which recovered from fault state, or nodes added dynamically in live network.
Generic NM allows SWCs communicate even if Generic NM fails to initialize or is yet to initialize.
Generic NM being a network independent module, works for any communication bus simultaneously as long as it is supported by AUTOSAR.
If no node needs the bus, then Generic NM puts the bus in sleep mode.

Generic NM module mainly performs two operations as follows:

Convert generic function calls to bus specific calls and vice versa: Function calls from Communication manager are bus independent in nature, Generic NM module converts these calls and “directs” them to bus specific calls which will be in CanNm for CAN or FrNm for FlexRay. It also converts the bus specific call backs to bus independent calls which are directed towards ComM.
Performs the role of NM coordinator: Generic NM module can be used to implement NM coordinator functionality in a separate ECU called Gateway ECU which is connected to multiple buses (like CAN bus, FlexRay,etc). Such functionality is required for performing synchronous shutdown of NM of bus (this means bus specific NM in ECU on the other end of the bus) in multiple buses scenario, such bus is called coordinated bus. Here synchronous means, all the nodes in the bus will shutdown (or move to power down state) by NM coordinator in sync because each node in the bus will be aware if any node is using bus or ready to sleep and if no node is using the bus, then all nodes will mutually go in power down state with help of NM coordinator. Generic NM module uses a special algorithm for implementing this functionality referred as coordinator algorithm. The NM coordinator keeps the bus awake if at least one of node in the network needs the bus, that means it won’t let others to sleep even if they want to! 😀 Every coordinated bus (ECU which should listen to NM coordinator) has configurable property which can be configured in Configurator software like Vector DaVinci Configurator “NmSelectiveNmChannel” if it is set to True, then NM coordinator will ignore such node and its shutdown is not under NM coordinator’s control or it will be asynchronous shutdown. If only NM coordinator is using the bus and all other coordinated buses are not using, then NM Coordinator puts whole bus to shutdown by sending NM messages to other nodes in the network and if there is no NM messages from other nodes in network, then NM Coordinator considers this as “no one needs the bus” and then shuts down the bus. Generic NM won’t help in “synchronous wakeup” as it is not required because Communication manager will wakeup the respective node when bus needs to be used by that nodes.

NM Coordinator functionality is optional, Generic NM either supports following:

NM interface functionality without NM coordinator functionality
NM interface functionality limited to support NM coordinator functionality only with ECUs using AUTOSAR based Network Management module.
NM interface functionality to support NM coordinator functionality with both, ECUs using AUTOSAR based NM as well as OSEK based NM. AUTOSAR is based on OSEK implementation, but it has more extensions compared to OSEK. So AUTOSAR uses different NM implementation than OSEK’s NM, there is thin line of difference. NM interface can support both type of NM implementations simultaneously, as AUTOSAR is backward compatible with OSEK.

Files generated for Generic NM

Only a single C file is generated for NM named as Nm.c. It have all the implementation of NM functionality as discussed above and as per the configuration. Some tools also implement macros instead of separate C file for realising NM functionality.

Four header files are generated namely:

Nm.h: This file contains function prototypes of functions in Nm.c file.
Nm_Cbk.h: This file contains the function prototypes call back functions in Nm.c file
Nm_Cfg.h: This file contains pre-compile time configurable parameters.
Nm_StackTypes.h: This file contains typedef and structures used in Nm.c file.

I hope I explained Generic NM interface well, if you have any doubts please comment below.

If you find any incorrect information in this article, then please help me improving it by contacting me.

Thanks for reading 🙂

Like us on Facebook!

Subscribe for newsletters!

Communication Stack – CAN

8 Comments / AUTOSAR Com Stack / By Alpha

Network Dependent Block of Communication Stack for CAN

Translate in your language

In my last article, we have discussed generic and bus independent blocks of AUTOSAR Communication stack in brief. If you have not read that article, then I recommend reading it before going further.

CAN Communication stack are a group of modules for vehicle communication system utilizing CAN bus. This provides a uniform interface to the CAN network along with hiding protocol and message properties from application. The application layer is only concerned with data, not with lower level operations like: which bus is used, or if the data to be transmitted will not fit in CAN frame, etc. These lower level operations are handled by Communication stack. CAN communication stack supports standard CAN as well as CAN FD (if supported by hardware).

Above figure shows the detailed layers involved in CAN communication stack in AUTOSAR. In this figure, only blocks like: communication services, communication hardware abstraction, communication drivers are considered (as we are discussing only Communication stack related blocks), but this time with detailed blocks in them. Some blocks are network/bus dependent (in dark blue color) and some are network/bus independent (in orange color), the independent ones exist as one instance per ECU or in other words the independent blocks will be reused if more than one type of network bus is used, for example CAN and FlexRay in single ECU will have their own respective bus dependent blocks but network/bus independent blocks will be reused. Lets see each block in brief :

1. CAN NM: This is CAN dependent module but it is hardware independent i.e. it will be used only if CAN bus is used in the application but its software implementation is hardware independent. Its main purpose is to coordinate between different modes of CAN network, like: bus sleep mode and normal operation. In addition to this, it also provides configurable features like implementing a service to detect all present nodes or check if all nodes are ready to sleep. CAN NM function provides a adaption layer between Network management Interface (Nm) and CAN Interface (CanIf). The CAN NM consists of three modes : Network Mode, Prepare Bus Sleep Mode, and Bus sleep mode. We will see this block in detail in future article. If you want to get understanding of generic Network Management then check out this link.

2. CAN State Manager (CanSM): AUTOSAR BSW provides a specific state manager for respective bus/network. CanSM is used to change modes of CAN network. In ECU, there can be multiple communication network/buses and each network has a unique network handle associated with it. The ComM module keeps track of communication modes of network by requesting from such network handles. ComM knows by its configuration which handle is assigned to CAN or FlexRay or any other network type. For CAN, ComM uses CanSM to request modes of CAN network. The CanSM module is responsible for controlling the flow abstraction of CAN networks in AUTOSAR. It changes the modes of CAN network according to requests sent from ComM module. CAN SM uses the API of CANIf module, any change of modes of CAN controller or CAN transceiver will be notified by CANIf to CanSM. Depending on this notifications and state of the CAN network state machine, which the CanSM module shall implement for each configured CAN network, the CanSM module notifies the ComM.

3. CAN Transport Protocol (CanTp): Many times the PDU(message) that needs to be transmitted or received may go beyond the maximum size of supported CAN message. For solving such problems and limitations of CAN, AUTOSAR implements CanTp block. Messages that do not fit into a single CAN frame are segmented into multiple parts, such that each can be transmitted in a single CAN frame. This block provides services to perform the segmentation of I-PDUs whose size is greater than maximum allowed size for CAN. This block also provides services which reassembles the received PDUs which are then further transferred to application layer by unpacking signals from it. CanTp also has services to detect errors in segmentation. CanTP is based on ISO 15765 which is standard for CAN. The PDUR determines whether to use this module or not by considering the size of PDU, if the PDU fits with a single CAN frame then it is forwarded directly to next module instead of CanTp module or if the PDU don’t fit in single CAN frame then that PDU goes through CanTp and then to lower layers. Same mechanism is followed when PDU is received.

4. CAN Interface (CanIf): It represents the interface to the services of CAN Driver for the upper communication layer. It provides unique interface to manage different hardware device types like CAN controller and CAN Transceiver according to ECU hardware layout. Thus multiple underlying internal or external CAN controllers/CAN transceivers can be controlled by CAN state manager (CanSM) uniformly. It controls CAN controller state transitions from CanSM and notifies state changes to upper layer. The CAN interface module consists of all the hardware independent tasks which belongs to the CAN communication device drivers of the ECU. These tasks are implemented once in the CAN interface module, so that underlying CAN device drivers can only focus on access and control of the corresponding specific CAN hardware device. CanIf fulfills main control and data flow requirements of the PDU router and upper layer communication modules of AUTOSAR COM stack. Requirements like: transmit request processing, transmit confirmation / receive indication / error notification and start / stop of a CAN Controller and thus waking up / participating on a network.

5. CAN Transceiver Driver: Whenever there is no on chip CAN transceiver in a MCU, external CAN transceiver is used which is generally on-board of ECU. This block provides drivers for such external on board CAN Transceiver chips. It supports CAN Transceiver chips which communicates on SPI.

6. Driver for external CAN ASIC: This as the name suggests, will provide drivers for CAN application specific Integrated Circuit (ASIC). There can be cases when standard CAN Transceiver chips are not suitable for a application, in that case this block comes in to picture. This is very rare case, majority of applications use standard CAN Transceiver chips.

Below we will see the journey of CAN message from signal to message which is ready to transmitted:

Above figure is a very simplified figure of journey of a CAN signal to becoming a ready to transmit message. The signal is created by the application layer and sent via RTE to AUTOSAR COM, till here signal oriented interface lasts. Below layers cannot differentiate between signals and only understands PDU. So, COM packs the signal into a PDU which is further transferred to PduR. PduR then transfers it to CanTp because in this case PDU is assumed to be greater than the maximum allowed size of CAN frame, then it will be segmented in multiple PDUs.You should also notice the PDU name changes for each layer, I explained this in other article. If you are not sure of PDU name changes then you should check out PDU changes link. The reverse pattern is followed while receiving CAN message, except the CanTp will reassemble PDU segments into a single PDU and transmit to above layers.

I hope I explained CAN communication stack in easy way. If you have any doubts then please ask it in comments box below.

If you find any errors in this page please report it.

Mistakes and errors are certain as I am human and human is a statue of mistakes!

Thanks for reading!!

Like us on Facebook!

Subscribe for newsletters!

Generic Blocks of Communication Stack

3 Comments / AUTOSAR Com Stack / By Alpha

Generic Blocks of Communication Stack

Translate in your language

In my last two articles (Intro to AUTOSAR and AUTOSAR BSW) we have discussed the AUTOSAR Layered architecture in brief and in detail respectively. But now we will go even more deep from today by focusing different stacks one by one. First we will see Communication Stack and will study stacks for each communication protocol like CAN, FlexRay, etc. in different posts for each type of protocol.

For ease of understanding, I have divided communication services block in network/bus dependent and independent blocks for ease of understanding.This article will only focus on explaining network/bus independent blocks of communication stack of AUTOSAR in brief. I will also be explaining each block in detail in my future articles. This will help in relating while reading posts explaining network/bus dependent blocks in communication stack by linking this post.

Above figure is a generic communication stack block diagram which shows only network independent blocks and all the Network dependent blocks will be replaced by respective communication protocol block for example: CAN will have all the CAN related blocks or FlexRay will have all the FlexRay related blocks.

In this figure, only blocks like: communication services, communication hardware abstraction, communication drivers are considered, but this time with detailed blocks in them. We have already seen these blocks in brief in AUTOSAR BSW tutorial, if you have not read that article yet then I recommend reading it first and then come back here. All blocks are network independent (in orange color), these independent blocks exist as one instance per ECU or in other words the independent blocks will be reused if more than one type of network bus is used for example CAN and FlexRay used simultaneously. Let us see them in brief:

1. Generic NM(Network Management) interface:

It is an adaptation layer between Communication Manager and the bus specific network management or network dependent blocks like CAN NM or FlexRay NM. This module only contains dispatcher. This module can also be used (optionally) in performing the role of NM coordinator where networks of different types can synchronously wake or sleep, in which a separate ECU called as gateway ECU can be dedicated. An AUTOSAR NM Interface implementation can either support:

NM Interface functionality without any NM coordinator functionality
NM Interface functionality with NM coordinator functionality limited to support synchronous shutdown of buses with AUTOSAR NM running on the buses
NM Interface functionality with NM coordinator functionality to support synchronous shutdown of busses with AUTOSAR NM and direct OSEK NM running on the busses

This module provides services to Communication Manager (ComM) and uses services of respective bus specific or network dependent Network Management adaptation layers like CanNm, FrNm, LinNm. This module converts the generic function calls to bus specific function calls of the bus specific Network Management layer. So whatever communication related functions calls are called from upper layer, this module forwards it to respective bus specific calls. It also converts the bus specific callbacks to generic callbacks to the Communication Manager. Now this is vice versa, all the callbacks received from lower layers (bus specific modules) are converted to generic callbacks, because above layers don’t “understand” network or bus they are just interested in data i.e. Signals. For more detailed explanation of Generic NM check out this article.

2. Diagnostic Log and Trace (Dlt) :

AUTOSAR has a nice feature for storing diagnostic information and also reading this information as needed either by developer or maintenance engineers with specialized tools. This module (Dlt) helps achieving the transmission of diagnostic information on the communication bus.This module receives information from DET(Default Error Tracer), DEM (Diagnostic Event Manager) , SW-Cs and RTE trace information. The Dlt transmits this information on communication buses to make this information visible to other devices on bus. In order to transmit messages on communication bus, Dlt interacts with PDUR. Dlt has a set of supported commands identified by service IDs, which start with 0x01 to 0x23. Lets see the Dlt interactions with other listed modules :

Dlt interaction with Software components: Dlt module offers interfaces which SWCs can use to send log and trace information to Dlt, which further can be read by maintenance engineers as and when needed.
Dlt interaction with RTE: RTE has a functionality called as VFB (Virtual Function Bus) Trace which is nothing but implicit forwarding of communication data which flows from SW-C to Dlt via RTE. Dlt module provides interface for VFB Trace. For it, the Dlt has to be configured as VFB Trace Client and while configuring, we can configure which events are traceable in the configuration of RTE module. We will see the configuration of this in detail in my configuration related articles.
Dlt interaction with DEM: DEM stores the events and messages generated from SW-Cs and BSW modules. These events are numbered by event IDs. Each time the state of a event is changed, DEM calls the Dlt_DemTriggerOnEventStatus function to notify Dlt of this change.Within this function, the DEM module provides the EventID of the event whose status has changed.In this function Dlt module compares the old to the new event status, If the event status is changed then Dlt will build a Dlt log message with the new status and send it by calling Dlt_SendLogMessage.
Dlt interaction with DET: SW-Cs and BSW modules can report errors to the DET module. Such errors can be forwarded to the Dlt module as messages with a suitable content using the Dlt_DetForwardErrorTrace function and can be seen by developer.

For more detailed information on this module checkout this article.

3. Diagnostic Communication Manager (DCM):
The DCM module receives a diagnostic message from the PduR module. The DCM module processes and checks internally the diagnostic message. As part of processing the requested diagnostic service, the DCM will interact with other BSW modules or with SW-Components (through the RTE) to obtain requested data or to execute requested commands. This processing is very service-specific. Typically, the DCM will assemble the gathered information and send a message back through the PduR module. Lets see interactions of this module with other modules:

Diagnostic Event Manager (DEM): The DEM module provides functionality for retrieving information related to fault memory (memory locations where faults are stored) using which the DCM responds to requests from tester by reading data from fault memory.
Protocol Data Unit Router (PduR): The PduR module provides functions for transmitting and receiving data.
Communication Manager(ComM): ComM module provides functions using which the DCM can indicate the “active” and “inactive” states in diagnostic communication. The DCM module provides functionality to handle the communication requirements from ComM “Full-/ Silent-/ No-Communication”. Additionally, the DCM module provides the functionality to enable and disable Diagnostic Communication if requested by the ComM module.
SW-C and RTE: The DCM module has the capability to analyze the received diagnostic request data stream and handles all functionalities related to diagnostic communication such as protocol handling and timing. Based on the analysis of the request data stream, the DCM module assembles the response data stream and delegates routines or IO-Control executions to SW-Cs .If any of the data elements or functional states cannot be provided by the DCM module itself the DCM requests data or functional states from SW-Cs via port interfaces or from other BSW modules through direct function-calls.
BSW Scheduler Module (SchM) : The SchM module provides functions to activate/cancel main processing functions.
EcuM: The EcuM can initialize the DCM module.
Mcu: The Mcu allows the DCM to perform a controller reset.

4. AUTOSAR COM:
This is one of the most important module of AUTOSAR communication. This can be understood well once I explain some basic terms of AUTOSAR communication.

Signal: AUTOSAR implements signal based communication. A signal is the smallest amount of information in a CAN message. A signal can be of any size from 1- bit to all 64 bits of CAN message. In other words, the CAN message is divided in bits called signals and the application works on signal. For this primitive data types is supported like int, char, etc. There can be even Signal Groups used when signals needs to be kept tightly with each other. Signal groups can be used to support complex data structure like structs. For more detailed information on signal check out this link.
PDU: In AUTOSAR context, the message is called as PDU (Protocol Data Unit). PDU can be roughly considered as a package of signals. This packing or unpacking of signals in a PDU is done by AUTOSAR COM while transmitting or receiving data respectively. For more detailed information on PDU check out this link.

Thus COM main function is packing/unpacking the signals in PDU during transmission or reception respectively. COM provides signal oriented interface to RTE. Below COM no module understands signal oriented interface. It also performs the function of communication transmission control and monitors received signals. External signal exchange between SW-Cs on different ECUs are routed through RTE via COM to PDU-Router and then to a bus system as configured during configuration.COM is further used for :

Route signals from received I-PDUs
Start or Stop I-PDUs.
Byte order conversion

5. Large Data COM (LdCom):
The AUTOSAR LdCom module provides an alternative Interaction Layer Mechanism. By focusing on spontaneous, non-cyclic communication without serializing, filtering and conversion an efficient implementation of the module without local buffers is achieved. LdCom is an additional means for sending and receiving signals along with Com but with more features as listed below. It handles mainly following functions:

Provision of signal oriented data interface for the RTE
Provision of received signals to RTE
Support of large and dynamic length data types
Support of IF and TP-based communication
Provision of PDU oriented data interface towards PduR

6. Protocol Data Unit Router (PduR):
PDU router as the name suggests is used to route the I-PDUs (for more information on this checkout I-PDU) between modules like communication interfaces modules (like CAN IF, LIN IF, etc ), DCM,AUTOSAR COM,etc. PDUs are identified by static PDU IDs. PDUR determines the destination of PDU by using the PDU ID and a static configuration table. PDUR don’t modify the data, instead it just routes the PDU to its destination.

The PDU Router module provides an API for modules below the PDU Router module (communication interface modules and transport protocol modules) and an API for modules directly above (e.g. DCM and COM) . Furthermore, the PDU Router module provides an interface for the I-PDU multiplexer (IPDUM) which is located beside the PDU Router. All these interfaces are constructed such that the operations required to pass data between the lower and upper layers are minimized.

The PDU Router module is part of the AUTOSAR Basic SW, and is mandatory instantiated in every AUTOSAR ECU.

7. IPDU Multiplexer (IpduM) :

PDU multiplexing means using the same PCI (Protocol Control Information) of a PDU (Protocol Data Unit) with more than one unique layout of its SDU (Service Data Unit) for more information on PCI and SDU read article on common terms of AUTOSAR on PDU. A selector field is a piece of the SDU of the multiplexed PDU. It is used to distinguish the contents of the multiplexed PDUs from each other. On sender-side, the I-PDU Multiplexer module is responsible to combine appropriate I-PDUs from COM to new, multiplexed I-PDUs and send them back to the PDU Router. On receiver-side, it is responsible to interpret the content of multiplexed I-PDUs and provide COM with its appropriate separated I-PDUs taking into account the value of the selector field.

8. Secure Onboard Communication(SecOC):

The SecOC module aims for resource-efficient and practicable authentication mechanisms for critical data on the level of PDUs. SecOC module receives I-PDUs from PduR, on it the SecOC module adds or process the security related information and reverts back the results in the form of I-PDU to PduR. PduR then further routes the I-PDU. SecOC module utilizes the cryptographic services and interacts with the RTE for key and counter management.

Don’t worry if you don’t understand any network/bus independent modules from above, I will be explaining each of them and network dependent blocks in detail in future articles. In this article, I just gave a brief information about them to help in understanding the bus/network dependent modules from high level which will help in understanding the network or bus dependent modules.