To download the PDF version click here: RTA-AN_BSW_BswM_PduGroupHandling.pdf

Introduction

Scope

This application note describes how to configure RTA-BSW in order to switch on/off I-PDUs communication.

A possible use case for this strategy is a case where the user needs to handle different Variants, and each Variant is characterized by different I-PDUs (and therefore each Variant has a different dbc associated).

Generally speaking, the strategy explained in this AN can be applicable in all the cases where the ASW needs to detect a change in the system/ECU status and consequently restrict/extend the communication turning off/on some of the I-PDUs.

Assumptions

Software

You must have the following ETAS software installed:

• ISOLAR-AB 5.0.1
• RTA-BSW 3.2

This application note could be used as a reference for any generic AR based project.

Prerequisites

An assumption of this Application Note is that the user is familiar with the BswM module and he is also familiar with Mode Management. The AN contains indications on how to configure BswM for Mode Management, but it is out of scope to provide theoretical details and concepts on Mode Management.

Strategy details

In this section it is detailed the strategy to follow in order to handle different variants, characterized by different dbc files, from the communication point of view.

The use case is the following:

1. The user has more ECU variants to handle
2. Each ECU variant is characterized by different dbc files
3. After the startup phase, the ASW shall be able to turn on just the I-PDUs that are associated to the current ECU Variant, and turn off all the other not relevant I-PDUs.

The strategy uses the PDU Group feature from Com Module and BswM Mode Management. The PDUs are grouped into PduGroups. Each PduGroup is associated to a specific variant.

This strategy has some advantages:

• It is possible to handle different variants using the Mode Management
• It is easy and fast to configure, high reusability

The main requirements to implement this strategy are:

1. All PDUs and Signals shall be defined in the System
2. PDUs and Signals shall have a unique name (AUTOSAR requirement)

In the proposed strategy, the actors are:

1. ASW: A SWC must act as Mode Requester
   • Check the current variant
   • Request to the BswM to switch to the Mode foreseen for that particular variant
2. Com Module
   • Receives the request from the BswM to switch on/off one or more PDU groups
3. BswM as Mode Manager
   • The BswM handles the Mode Switch request
   • The BswM send the request to the Com to switch on/off the PDU groups (using the configured Action Lists)

Strategy Implementation

In this chapter it is described how to implement the strategy previously described, for each of the actor identified before.

Application software configuration

The ASW configuration is split in two parts. In this section we create all the ASW elements that are needed for the BswM configuration. In the second part of the ASW configuration, we will complete the workflow with the elements that will be generated after the configuration of the BSW.

Creation of the Mode Declaration

The first step is to create the Mode Declaration and therefore create the two modes that we need. In our example, we suppose to have to variants to handle.

Creation of the Interface

Now it is possible to create the interface needed by the ASW to communicate the mode switch request to the BSW.

In order to create this interface, double click on an existing interface to open the editor. Switch to the tab "Mode Switch Interface" and an MS interface and a Mode Declaration Group Prototype as shown in the screenshot:

Creation of the Data Mapping

Another step needed before to configure the BSW is to create the Data Mapping that will be referenced in the BswM module later on.

To create the Data Mapping, using the AR explore open the sub-folder "Data Type Mapping Sets" and add a new element into it, as shown below:

Double click on the created element to open the editor. Switch to the "Mode Request Type Map" and then create a new map. Assign uint8 as "implementation Data Type", for example.

Now you have everything is needed in the ASW to proceed with the BSW configuration. Please follow the next sections for details in the configuration.

Com Module configuration

In the Com module the PDU Groups shall be created and the relative PDUs shall be added.

The first step is to create the ComIPduGroups, in our example we create two additional groups for the two variants.

Now, it is possible to reference the IPDUs to a particular group. Open an existing PDU and change the reference as shown in the picture below:

In the screenshot, you can see that the IPDU has been assigned to the group created for Variant2.

The user shall repeat the configuration assigning all the IPdu to the correct group.

BswM as Mode Manager

As previously described, the BswM shall act as a Mode Manager. The BswM is the only BSW module that is, according to AUTOSAR specifications, able to call the Com API Com_IpduGroupControl and enable/disable the transmission of one or more PDU groups.

In order to do so, you need to follow the configuration described in this section.

Adding a new ModeRequestPort

The Mode Request Port must be added to the BswM configuration. This port is needed by the BswM in order to receive the mode switch request from the ASW. Please add the new BswMModeRequestPort as shown in the picture below.

Call the created MRP "BswMMRPSwcSelectVariant" and configure it as shown below:

Under the container "BswMMRPSwcSelectVariant", create the child "BswMModeRequestSource" and then the "BswMSwcModeNotification". Then configure this last one as shown in the pictures, assigning the reference to the Mode Request Group (in our case, called "MDGPMSISelectVariant"):

Create new BswMModeConditions

The second step is to configure new BswMModeConditions. Supposing to have two variants to handle, and consequently have to PDU Groups to switch on/off, you can create two new Mode Conditions.

Configure now the sub-container BswMModeDeclaration for each of Mode Condition:

The BswMModeDeclaration shall contain the reference to the Mode value against which will be done the comparison. In one case will be "EnableVariant1", while in the second case will be "EnableVariant2".

Configuration of new Logical Expressions

Now it is possible to add new Logical Expression. Again, two Logical Expression are needed, one for each variant we want to handle.

The Logical expression may contain a "dummy" check, therefore the BswMLogicalOperator is not mandatory to be configured. Instead, you shall add the reference to the BswM MC you created before. For example, for the Logical Expression related to the Variant1, the configuration will be the following:

The Logical Expression for Variant2 will be similarly configured with the reference to the MC of the second Variant.

Creation of the new Action Rules

Now it is possible to configure the Action Rules associated to the request to switch between the two variants.

You can add two AR, one for each variant to be handled, as shown in the picture below.

More in detail, the configuration of each AR will be as shown in the pictures below.

Add the Mapping set reference

The BswM needs the reference to the Data Mapping Set, previously created in the ASW.

Create new BswMActions

You can now add new BswM Action Items (AI), which will be executed when the associated Action List (AL) is triggered (see next sections for the reference on the AL creation).

It is needed to create two new AI, one for each variant:

\

For each AI, the correct action to be selected for our purpose is "BswMPduGroupSwitch". For each variant, you can then configure which PDU groups shall be disabled and which ones shall be enabled, as shown in the picture below. The AI for the Variant 2 shall be configured similarly.

Creation of the new Action Lists

The last step for the BswM configuration is to create the new Action Lists needed. Each of them shall contain the needed Action Items:

BSW Generation and BswM Service SW-C

Now the BswM configuration is complete and it is possible to generate the BSW. After the generation, you can notice that also the BswM Service SW-C has been updated with new interfaces to handle the Mode Switch Request coming from another SW-C. The next sections contains details on how to integrate the ASW with the changes done in the BswM.

Application Software - Integration with the BswM

Now it is needed to modify the ASW to communicate with the BswM and request for Mode Switch.

Modification to the SW-C

In our example, we decided that Base_SWC will be the SWC in charge to request the Mode Switch to the BswM. For this reason, we need to add to it the needed interface for mode management.

Add the ProvidePort selecting MSI_SelectVariant as Port Interface.

Add the DataMappingSet related to the SelectVariant:

Add a new Runnable:

And associate a Mode Point to the created Runnable Entity:

Add a new timing event for the RE:

Using the AR Explorer, open the Ecuc Value Collections with the RTE Editor:

Finally, the Runnable Entities generated for the BswM shall be mapped to the Os Task, as well as the new Runnable Entity created for the SW-C.

Connections on the Top Level Composition

The last step for the configuration is to connect the Base_SWC with the BswM Service SW Component. Open the TopLevelComposition with the Composition Editor, switch to the tab "Manual Connection Editor" and create the new connection as below:

Now the Composition is updated and it is possible to re-generate the ECU Extract. To do so, right click on the System and then on "Create ECUExtract".

Untick the box "Update existing ECUExtract" and then the Finish button.

Finally, generate the RTE with the options shown in the picture below.

C Code for the Base_SWC

Now that the RTE has been generated and all the configuration has been updated, we can add some test code in the new Runnable created for the Base_SWC.

The aim is to test the switch between the two variants, therefore we can simply use a state variable into the runnable.

#define ENABLE_VARIANT_1 	0u
#define ENABLE_VARIANT_2 	1u

uint8 variant_state = 0u;

FUNC(void, BswM_Test_CODE) RE_Variant_SWC(void)
{		
	if (variant_state == 0)
	{
		Rte_Switch_Base_SWC_PP_BswM_SelectVariant_MDGP_MSI_SelectVariant(ENABLE_VARIANT_1);
	}
	else
	{
		Rte_Switch_Base_SWC_PP_BswM_SelectVariant_MDGP_MSI_SelectVariant(ENABLE_VARIANT_2);
	}
}

During the testing, we can force the variable to a specific value to trigger the switch between the two Variants. Monitoring the CAN communication with the PC, you will be able to see the ECU stopping/starting the IPDU Groups according to the selected variant.

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.