Introduction
This example workflow describes how to create a basic Cdd in an RTA-CAR project.
The steps required to create and initially configure an RTA-CAR project are covered in the other workflows in this User Guide, so in this workflow we take an existing single core project (based on the VRTA_Standard Starter Kit for RTA-CAR 8) and we extend that sample project to contain a Cdd.
If you wish to follow along with this workflow, you will need to import the aforementioned Start Kit into your ISOLAR-AB workspace.
Prerequisites
The workflow below is designed to be stand-alone and it does not have any prerequisites beyond the import of the Starter Kit.
It is assumed that you are already familiar with how to create and configure an AUTOSAR project with ISOLAR-AB.
If you’ve not done so already, we recommend that you review (and preferably work through) Workflows 01, 02 and 03 to gain a better understanding of ISOLAR-AB and the tools available to create and configure an AUTOSAR project.
Understanding Cdd in AUTOSAR Context
A Complex Driver (Cdd) is a software entity not standardized by AUTOSAR that can access or be accessed via AUTOSAR Interfaces and/or Basic Software Modules APIs.
- A CDD may need to interface to modules of the layered software architecture
- A module of the layered software architecture may need to interface to a CDD
- A CDD may need to interface SW-Cs via Rte
The project will be composed by an application SWC that will exchange data with the CDD. The application SWC will have a required port for received data and a provided port for transmitted data. The CDD will be a CDD-SWC with ports complementary to the application SWC.
Since in this example an existing driver will be used, taken from the ETAS Virtual MCAL, the CDD SWC will actually be a simple wrapper of functions that creates a proper interface between RTE and the driver.
The picture below shows a building block view of the project we are going to create:
Workflow Summary
1.Create a New Interface
First right click on software and select Create Interface → Create Port Interface → Sender Receiver Interface
Name this new Interface "Data Buffer" and place it into the existing arxml file Interfaces.arxml.
Next double click on the newly created interface and create 4 VariableDataPrototypes by first selecting the MySRInterface interface in the table then clicking Add VariableDataPrototype:
Rename this new item to LEDValue and set the type reference to boolean:
2.Create a New Cdd SWC
Now we have created the required interface, we need to create the SWC for the Cdd to interact with the RTE and other SWC's. Click on Software and select Create Component → Complex Device Driver sw Component Type
For the purpose of this guide we named the SWC MyCdd and created a new AR Package /ARXML file to store this in (Cdd.arxml)
3.Create New SWC Ports
Double click on the newly created Cdd SWC MyCdd and this will open it in the component editor.
Since we have already created the required interface we can now created ports within the Cdd SWC to use this. Click the RPorts.. link.
Select SenderReceiverInterfaces and then select the new interface we created MySRInterace:
Then rename the port:
4.Create New Internal Behaviour
To create runnables in a SWC an Internal Behaviour container is required. Click on the green '+' icon at the top right of the component editor you have open:
Assign the new internal behaviour a name - in this example we use CddInternalBehaviour. Then hit OK.
5.Create a New Runnable
Similar to an application SWC we need to create runnables to run the code in our Cdd. In this case we need to create a runnable for setting the value of an Pin in the MCAL.
To create a runnable first navigate to the Functions tab and select the + Runnables link:
The naming we used for this runnable is Cdd_MainFunction.
6.Add Data Access Points for Runnables
Click on the data access points tab for the new runnable we created and press the + Access Points... link.
Click on the DataReceivePointByValues and select the new port you have created:
7.Add Event's for Runnables
Now finally for our Cdd we ned to set an event that will trigger the execution of the runnable. In this example we are going to configure the system so that on reception of a specific CAN signal we change the value of the pin through our Cdd. Meaning that our runnable should be triggered by a data received event. To do this select the Events tab.
Then select the + icon and select DataReceivedEvent:
Then select the new port you have created. Then rename the created event to DRE_PinValue
8. Making relevant changes inside MasterSWC
Now we have set up a RPort in our Cdd SWC - we now need to setup a corresponding PPort. The MasterSWC is the entry point in the application software for receiving in test codes sent over Can. From here we can check for a certain test code and then communicate to our Cdd to set a value of a pin.
Open MasterSWC under Software → Components by double click on it.
Then on the main tab select the PPorts... link and select the MySRInterface interface:
Then rename the new port to PPort_PinValue:
Now move to the Functions tab and select RE_RunTest then select the Data Access Points tab and click +Access Points.
In the DataAccessPoint dialog select DataSendPoints and select our new PPort_PinValue:
9. Mapping Cdd to Composition and ECU
Since the Cdd SWC is new before we connect our new ports we need to map the Cdd SWC to the composition and ECU. Navigate to System → System Info and right click on System item and select Open With → Composition Editor:
Then select the + icon and select component prototype :
Then select MyCdd and hit OK
Now at the bottom of the editor click on the manual connection tab:
Now using the Source Component and Target Component boxes select the MasterSWC as the source and the CDD SWC as the source as follows:
You will then be able to tick MyPPort and MyRPort and select the connector button in the centre to add the connection.
This will add a new entry for the connection as follows:
Then again using System → System Info and right click on System item this time select Open With → SWC to ECU Mapping Editor:
You will now be able to see on the right hand side the CDD SWC. Drag this onto the ECU:
save and then exit the editor.
10. Updating the ECU Extract
Navigate to System → System Info and right click on System and select Create ECU Extract.
Then select OK in the popup:
11. Mapping the Cdd Runnable to a Task
Now so our runnable gets executed we need to map it to a task. In the ECU Configurator navigate to Bsw Modules → Ecuc Value Collection and double click the item as follows:
You should now be able to see the DataReceivedEvent for our Cdd_MainFunction. Drag this onto the Os Task OsTask_ASW:
12. Add Cdd Init function to EcuM Driver Init List
Our Cdd will need an init function for the Port Mcal module to be initialised/de-initialised. For this we need to add these two items in the EcuM.
Open the EcuM module under Bsw Modules >Mode Mgm > EcuM.
Navigate to EcuMConfiguration > EcuMDriverInitListOne and click on EcuMDriverInitItems:
Click on the Create EcuMDriverInitItem link... this will add a new entry in the table. Set the name of the new entry to the name of your init function. In this case we have named the function Cdd_Init.
Set the ModuleID, ModuleParamter and ModuleService as shown above.
12. Generate Project
Open the RTA Code Generator Dialog and navigate to RTE "Include AR Files" and select the Cdd.arxml we created:
Now click the RTA Code Generator and select Generate All
13. Example Code
Since we added our Cdd Initialisation function to the EcuM driver init list we need an implementation of this function. In this example this is very simple (a direct mapping) since we are just accessing the MCAL Dio module so all we need to do in this function is call Port_Init as follows:
For the purpose of this workflow we are just creating a basic Cdd SWC to control a pin in the virtual MCAL. However in reality this can be used for using MCAL modules not exposed by a accompanying BSW module.
But for this example in the Cdd_MainFunction runnable we created we just read in the boolean from the MasterSWC and then turn the pin ON/OFF based off of that value:
The value to set the PIN to is passed in from the MasterSWC which is received in from CAN. The value of the pin is decided based off the CAN Frame sent in.
Alternatively this could be done from the Cdd itself directly interacting with the CAN MCAL module - but this is out of the scope of this application note.
The results of this pin being set can be seen in the VRTA Monitor. If you open the monitor and set the DIO module to auto refresh:
You will be able to see the value change when sending CAN Frames on ID 0x14. Sending any odd value will turn the pin on, any even value will turn the pin off.
Pin Off: Pin On:
