Introduction

This application note (AN) describes a simple implementation of UDS service 0x28 using RTA-BSW. The implementation of this service requires a mode switch operation performed by the BswM, thus involves the configuration of both Dcm (UDS protocol side) and BswM (mode switch).

Communication Control is an UDS service (service ID 0x28) used to selectively enable/disable the bus communication via diagnostic line. This service is quite useful in context in which the communication want to be stopped for all or a group of ECU (for example during a SW download in order to maximize the available bandwidth).

The UDS specification supports enabling/disabling the communication in many different ways, and for different “communication types” (i.e. normal communication, network management communication, etc.). In this AN we will show the case of disabling Tx/Rx for normal communication only.

Assumptions

You must have the following ETAS software installed:

• ISOLAR-AB 4.0.2
• RTA-BSW 3.1

This AN could be used as a reference for any generic AR based project. The reference bus used in this document is the CAN bus.

Dcm Configuration

Dcm Dsd Configuration

The first thing required to implement service 0x28 is to add the service to the Dcm service table. Add a service named “CommunicationControl” to the DcmDsd section:

Configure the service with the below values (note that the initialization function could be required from some BSW version so check if it is defined).

Add the configuration of your required subservices are needed. For example the below depicts subservice 0x03 (DisableTxRx).

Dcm Dsp Configuration

Now the Dsd (Dcm Service Dispatcher) configuration is completed, so the service will be handled by the Dcm. To complete the module configuration it's necessary to add a Dsp (Dcm Service Processor) CommunicationControl configuration, so go to the DcmDsp configuration, locate CommunicationControl section and create a DcmDspComControlAllChannels reference. The reference needs to point to the ComM channel reference as depicted here:

Regenerate the Bsw now, in order to generate the Com Control implementation.

BswM Configuration

The BswM must be configured to perform the mode switch on reception of the Communication Control command. The steps required:

• Create a Mode Request Port (MRP)
• Create a Mode Condition (MC)
• Create a Logical Expression (LE)
• Implement a specific Action List (AL)
• Create an Arbitration Rule (AR)

The Mode Request Port defines a connection to the BswM used to pass requests or indicate modes from/to the BswM. These interfaces are SWCD ports when the request originates from an application SWCs or as C functions if a BSW module makes the request.

The Mode Condition describes a condition to be evaluated as a part of a logical expression. e.g. equal to COMM_NO_COMUNICATION.

The Logical Expression describes the logic used for mode arbitration. An expression is made up of one or more conditions (see above) the result of each evaluation is aggregated with a logical operator (AND, NAND, OR, XOR). Operator is only required therefore if there are more than one conditions.

The Arbitration Rule contains a logical expression, initial boolean state, and instructions on what to do if the expression is evaluated false or true (Action list to execute).

The Action List is a list of Action Items which are functions (actions) to be executed as a result of an Arbitration Rule evaluation (either to TRUE or FALSE).

The configuration of BswM can be visualised as the following:

Mode Request Port

To create an MRP open the BswM config in the BSW editor and go to BswMArbritration/BswMModeRequestPort and create a new item (e.g. called BswM_MRP_CommStopCom).

The BswMRequestProcessing method must be set, the options are IMMEDIATE or DEFERRED (below).

With the IMMEDIATE option the request is as the request is raised, while using the DEFERRED option a job request is placed and the request is processed in the BswM periodic main function.

You also need to select the right Mode Port Source (in this case BswMDcmComModeRequest), and reference from there the ComM channel:

Mode Condition

After the MRP is defined you have to configure the Mode Condition with the following parameters:

ConditionValue/BswMode - symbolic name of a certain mode/state that can be requested/indicated by the BSW modules. (e.g. DCM_DISABLE_RX_TX_NORMAL)

ConditionType - specifies what kind of comparison that is made for the evaluation of the mode condition. (e.g. BSWM_EQUALS).

ConditionMode - references the mode request port that is used for the condition, defined previously.

All the possible values of BswMode are listed below:

• DCM_ENABLE_RX_TX_NORM                       0x00
• DCM_ENABLE_RX_DISABLE_TX_NORM        0x01
• DCM_DISABLE_RX_ENABLE_TX_NORM        0x02
• DCM_DISABLE_RX_TX_NORMAL                  0x03
• DCM_ENABLE_RX_TX_NM                            0x04
• DCM_ENABLE_RX_DISABLE_TX_NM             0x05
• DCM_DISABLE_RX_ENABLE_TX_NM             0x06
• DCM_DISABLE_RX_TX_NM                           0x07
• DCM_ENABLE_RX_TX_NORM_NM                0x08 
• DCM_ENABLE_RX_DISABLE_TX_NORM_NM 0x09
• DCM_DISABLE_RX_ENABLE_TX_NORM_NM 0x0A
• DCM_DISABLE_RX_TX_NORM_NM               0x0B

Logical Expression

Now you need to create a logical expression that reference the Mode Condition created before. If you don’t need to specify a complex expression just reference the mode condition, as in the example below:

Action List

Now you need to create an Action List to execute once the Arbitration Rule evaluates to a specific logical value (in this example we need an action list with a single action item that stops the communication on the bus).

The parameter BswMActionListExecution controls if the corresponding action list shall be executed every time the rule is evaluated or only when the result of the evaluation changes. "BSWM_CONDITION" - action list shall be executed every time the rule is evaluated. "BSWM_TRIGGER" - action list shall be executed, only when the result of the evaluation changes.

In the case of stop Normal Communication the correct action items to include in the action list are:

• BswM_ALI_StopCom: BswMComMAllowCom set to false
• BswM_ALI_StopPdu: BswMPduGroupSwitch set to false (with Rx and Tx group referenced)

Pictures below shows the Action Items configuration:

The action list configuration is highly dependent on the specific subservice you want to implement, so, just for instance, the implementation of enable TX and RX requires a different action list to be executed.

Arbitration Rule

Finally you need an arbitration rule that evaluates the logical expression and triggers the previously defined Action List:

Regenerate the BSW to update the BswM source code.

Rte Configuration

Rte Bsw RequiredModeGroupConnection

In order for the RTE to be generated you need to configure the RteBswRequiredModeGroupConnection. To do this you need to find the RTE section inside the EcuC Module Configuration Values:

In the RTE editor you then need to select the RteBswRequiredModeGroupConnection inside the Dcm Instance of RteBswModulesInstances.

Then you’ll have to set the following references:

RteBswProvidedModeGroupRef - DcmCommunicationControl_ComMChannel_Can_Network_Channel

RteBswRequiredModeGroupRef - R_DcmCommunicationControl_ComMChannel_Can_Network_Channel

RteBswProvidedModeGrpModInstRef - Dcm

At this point you can re-generate first the Bsw and then the Rte in order to make the configuration effective. The service and mode switch are now implemented.

Conclusion

The samples and advice provided with this AN are provided to inform and guide and should not be assumed to be universally applicable. It is your responsibility to interpret the content and apply it to your specific use case.