This document will guide you on how to use CANoe as a test tool for an Adaptive application, that is built based on a MICROSAR Adaptive BSW Package. A MICROSAR Adaptive delivery contains some examples. We will use one of these examples that is called start application. Connect it to CANoe and simulate parts of it with its toolbox. These instructions are written based on an Adaptive MICROSAR stack version r8.00.02 (D94) interacting with CANoe 17 and CANoe 18. With every newer release of the Adaptive stack or CANoe, there might be deviations from this guide, though it shall be possible to adapt the commands with the user guides provided with the tools.
The start application contains one Adaptive machine with multiple executables. It does not realize an automotive user story, but uses all relevant parts of an Adaptive application with comprehensive names. It consists of several use cases. In this guide, we will focus on the Communication Management use case (StartApplicationCmClient1 and StartApplicationCmServer1).
It relies on the SomeIP Daemon that is part of the delivery. Communication in between the executables is realized with SomeIP and IPC. The original start application may use the execution manager and also contains some python scripts to trigger the single executables. This guide is based on the usage of a VM with Ubuntu 22.04. We will use the Linux VM for building the stack including the start application example and for running the Adaptive executables. Any other virtualization platform may be used as long as it is suitable to build the Adaptive stack and the SIL Kit components.
CANoe will connect to the VM via Vector SIL Kit as a SIL Kit participant. The counterpart running on the VM is the SIL Kit Adapter TAP which connects as another participant to the SIL Kit network as well.
After decrypting and unpacking the Adaptive delivery, use the Doc/UserManuals/InstallationGuide_MICROSARAdaptive.pdf manual to get the latest requirements and instructions to set up your Linux system and then to build and install all the components of the stack. You can omit the sections for Yocto Linux and QNX.
The start application is part of the delivery at Examples/startapplication. It comes with its own user manual Doc/UserManuals/UserManual_StartApplication.pdf. Besides a description of all single components of the start application, it contains instructions on how to build and install the start application with TACO. Follow these instructions and end after the section Install Runtime. We don't need to execute the build script. And we won't create a network adapter for the start application as the next step of the user guide suggests, since we want to connect it to CANoe via the SIL Kit Adapter TAP.
Hint: If you want to get rid of the non-fatal errors and warnings due to the missing execution manger you can disable its usage in the CMakeLists.txt of the start application by setting AMSR_ENABLE_EXEC_MANAGER to OFF.
Download a preview or release of the adapter directly from Vector SIL Kit Adapter TAP Releases or build the Vector SIL Kit Adapter TAP on your own.
For both options you need a sil-kit-registry contained in the SIL Kit Release, which you can download directly from Vector SIL Kit Releases.
Before you start the adapter there always needs to be a sil-kit-registry running. The easiest way is to start it like this in your Linux system:
/path/to/SilKit-x.y.z-$ubuntu/SilKit/bin/sil-kit-registry --listen-uri 'silkit://0.0.0.0:8501'We recommend using a designated URI (e.g. "0.0.0.0:8501") to avoid issues with reachability and the execution sequence when using the default setting (localhost).
In this section, you will find an overview of the setup and step-by-step instructions to attach the SIL Kit Adapter TAP to the Adaptive start application. Alternatively there is also a helper-script which can be seen as a template automating all these steps.
This sketch shows the components of our setup and how they are connected:
+-----------------------------------------+
| |
| Server |
| IP 192.168.7.2 |
| Port:31404 |
| |
+-----------------------------------------+
<=>
sikit_tap as network endpoint in NetNs
<=>
+--[ SomeIP and Crypto Daemon in NetNs ]--+ +------[ SIL Kit Adapter TAP ]------+
| silkit_tap added to NetNs | <= ------ silkit_tap ------ => | TapConnection to silkit_tap |
| <=> Server Com via SomeIP Daemon | | <=> virtual (SIL Kit) Ethernet1 |
+-----------------------------------------+ +-----------------------------------+
<=>
SIL Kit
<=>
+-------------[ Vector CANoe ]------------+ +-------[ SIL Kit Registry ]--------+
| | <= ------- SIL Kit -------- => | |
| Client | | |
| IP 192.168.7.1 | | |
| Port:31404 | | |
| | | |
+-----------------------------------------+ +-----------------------------------+
The user manual of the start application suggests to create a network adapter with the IP address 192.168.7.2, we omitted this step and will now create a TAP device in the Linux system with the same address. The TAP device will enable the connection with CANoe using the Vector SIL Kit Adapter TAP. The TAP device is put in an extra namespace to separate the traffic completely. The Vector SIL Kit Adapter TAP needs to run before moving the TAP device to the network namespace. Finally the SomeIP Daemon has to be started in context of this namespace. It is a good idea to put all the necessary commands in a shell script and also extend it with some commands to kill the applications from a previous run (see helper-script as a possible template).
-
Create TAP device
silkit_tapsudo ip tuntap add dev silkit_tap mode tap
-
Start the Vector SIL Kit Adapter TAP and set the network name to the same one that will be used by CANoe.
/path/to/sil-kit-adapters-tap/bin/sil-kit-adapter-tap --network 'Ethernet1'The sil-kit-registry will announce a connected participant:
[date time] [SilKitRegistry] [info] Sending known participant message to EthernetTapDevice
-
Move the TAP device "silkit_tap" to the network namespace "tap_demo_ns"
sudo ip netns add tap_demo_ns sudo ip link set silkit_tap netns tap_demo_ns -
Configure the TAP device "silkit_tap" to the IP address used by the Adaptive application. The server StartApplicationCmServer1 of the start application e.g. uses the network endpoint 192.168.7.2.
sudo ip -netns tap_demo_ns addr add 192.168.7.2/16 dev silkit_tap sudo ip -netns tap_demo_ns link set silkit_tap up -
To avoid integrity check issues with development states of the SUT it should be disabled:
export AMSR_DISABLE_INTEGRITY_CHECK=1Hint: This export needs to be done in every terminal environment where an executable from the start application is started. This also applies to the crypto and SOME/IP daemon.
-
The crypto daemon may be started in the designated network namespace at this point. Starting the crypto daemon could look like this, just replace
$INSTALL_PATH_CRYPTO_DAEMONwith the suitable path (e.g.$AMSR_SRC_DIR/Examples/startapplication/build/gcc7_linux_x86_64/install/opt/amsr_crypto_daemon):cd ${INSTALL_PATH_CRYPTO_DAEMON} sudo -E nsenter --net=/var/run/netns/tap_demo_ns ./bin/amsr_crypto_daemon
-
The SOME/IP daemon may be started in the designated network namespace at this point. A configuration file for this daemon is needed. Starting the SOME/IP daemon with a config could look like this, just replace
$INSTALL_PATH_SOMEIPD_POSIXwith the suitable path (e.g$AMSR_SRC_DIR/Examples/startapplication/build/gcc7_linux_x86_64/install/opt/amsr_someipd_daemon):cd ${INSTALL_PATH_SOMEIPD_POSIX} sudo -E nsenter --net=/var/run/netns/tap_demo_ns ./bin/amsr_someipd_daemon -c ./etc/someipd-posix.json
At this point, the server executable can be started in the Linux system. For the example, it is not necessary to use the Execution Manager and it is enough to start the startapp_cm_server1. The executable provides the StartApplicationService1 service and the SOME/IP Daemon will dispatch it. The StartApplicationMethod1 method will increment the received value by 1, set the StartApplicationEvent1 and update the StartApplicationField1.
cd ${AMSR_SRC_DIR}/Examples/startapplication/build/gcc7_linux_x86_64/install/opt/startapp_cm_server1/
./bin/startapp_cm_server1Hint: It is totally fine to see error messages like shown below, as long as you got the feedback that the actual application you just started is running. The error message are shown due to the fact that we don't use the execution manager for this demo.
Finally it is time to setup a CANoe configuration as a SIL Kit participant which serves as a client mockup for our server application under tests. Depending on the CANoe version there are different workflows available to achieve this. The details for the individual workflows are listed in the sections below.
Important Hint: What is common for both workflows is that you have to leave out the .arxml files which belong to the client executable when using the AUTOSAR Preprocessor in CANoe to merge the system descriptions. Otherwise the client mockup can not be created. In this particular demo this will be the following selected files to omit:
The step-by-step instructions in this section showcase the more modern approach via the CANoe Simulation Setup and Distributed Objects.
The step-by-step instructions in this section showcase the legacy workflow via the CANoe Communication Setup and Communication Objects.
The step-by-step instructions in this section apply to both workflows showcased above.
Start the simulation in CANoe. The sil-kit-registry will announce a new participant:
[date time] [SilKitRegistry] [info] Sending known participant message to CANoe
In the CANoe trace window you can see the services periodically being offered by the server running in the Linux system and the subscription of the services:
Executing the test in CANoe shows the communication between CANoe and the server running on the Linux system over Ethernet:
The CANoe Protocol Monitor will give you a good overview of the involved participants, the multicast phase of the service discovery and the actual SOME/IP communication:
