Introduction

This application note is going to show how basic changes to the ethernet configuration can be made in order to change/add to the functionality. This article will cover:

• Changing the port which the ECU will transmit from/to
• Changing the IP Address which the ECU will transmit from/to
• Creating a new signal with its own runnable, with different functionality to the existing signal

This application note will use the Extended Starter Kit as a basis. It will also show how EthMaster, a tool packaged with the Extended Starter Kit, can be used to transmit and receive messages from the ECU.

Changing The Port

The existing configuration has the ECU use port 6807 and the server use port 15 (ECU IP = 192.168.1.10, Server IP = 192.168.1.1).

Changing the port which the ECU receives on (Local Port)

The port which the ECU receives on is defined by the /SoAd/SoAdConfig/SoAdSocketConnectionGroup/SoAdSocketLocalPort configuration item. Local ports are specific to a SocketConnectionGroup, this means that any socket connections within a socket group will use the same port. The local port must be unique to each SocketConnectionGroup. This is because the socket adapter uses an incoming PDUs port in order to help determine which SocketConnectionGroup the PDU belongs to.

Changing this will mean that sending the packet using the previous configuration in EthMaster will result in the ECU sending an ICMP packet stating that the port is unreachable.

In this case the port has been changed to 555. If EthMaster is changed so that the packet is sent to port 555 on the ECU then then ECU will respond correctly (by adding 1 to the first byte of the message).

Changing the port which the ECU receives from/Transmits to (Remote Port)

The port which the server transmits from is defined by the /SoAd/SoAdConfig/SoAdSocketConnectionGroup/SoAdSocketConnection/SoAdSocketRemoteAddress/SoAdSocketRemotePort configuration item. Remote ports are specific to a Socket Connection and can also be given as a Wildcard value, setting it to 0, which will cause the ECU to allow connections from any remote port. Note that when there are multiple SocketConnections within one SocketConnectionGroup, using a wildcard for more than one SocketConnection should be avoided, as this may prevent the SoAd module from determining which SocketConnection a packet belongs to, and therefore stops the PDU from being routed to the correct upper layer.

 Changing this will mean that when sending the packet using the old port (15), the ECU will ignore the packet and not respond. The ECU will respond if we use the new port (in this case it has been changed to 16).

Changing The IP Address

Changing the IP Address of the ECU (Local IP Address)

The extended starter kit uses a statically assigned IP address for its local address. By default it is 192.168.1.10. The address can be configured by changing the /TcpIp/TcpIpConfig/TcpIpLocalAddr/TcpIpStaticIpAddressConfig/TcpIpStaticIpAddress configuration item. Changing this will result in all of the SocketConnections using the TcpIpLocalAddr changing their IP Address.

Changing the IP Address of the server (Remote IP Address)

The remote IP Address is defined in the same location as the Remote Port, and is also unique to a SocketConnection. It specifies which IP address the ECU will receive the message from. It can be set as a wildcard, by setting it to ANY, to allow any IP address to send a message to the ECU or it can be set as an IP address to allow messages from only the specified IP. The address can be defined in the /SoAd/SoAdConfig/SoAdSocketConnectionGroup/SoAdSocketConnection/SoAdSocketRemoteAddress/SoAdSocketRemoteIpAddress configuration item.

Creating a new Ethernet Signal

This will be a short workflow which will start from the extended starter kit and will result in the addition of an extra signal. It will take in a 4 byte message and reply with another 4 byte message. Instead of adding 1 to the buffer and replying we will subtract 1 from the buffer and then reply.

Step 1. Creating the new ISignals and ISignalPdus

First new ISignals for sending and receiving should be created. This can be done by right clicking on System > Signals and Signal Groups > ISignals.

The corresponding system signal should have been created by this action, it can be helpful to rename the system signal in order to distinguish better between the ISignal and the system signal.

After an ISignal and System Signal for both directions have been created an ISignalPdu should be created, also for each direction. To create an ISignalPdu right click on System > Signals and Signal Groups > Pdus and click "Create Elements | ISignal PDU".

The ISignal should then be mapped to the ISignalPdu. This can be done by double clicking the newly created PDU and then dragging the correct signal into the table. 

Step 2. BSW Configuration

This step will involve the creation of the PDUs within the BSW, the linking between BSW and RTE (using the COM module), and the routing of the PDUs between each BSW module. First the PDUs should be created. Navigate to the EcuC BSW module (In the ECU Navigator, BSW Modules > Other Modules > EcuC). Four PDUs need to be added to the PDU collection. Each PDU represents the data being transferred between a BSW module. The route that the data will take is: SoAd → PduR → COM (For receiving, the opposite will be true for sending).

The second step will be to link the RTE and the BSW PDUs/signals. This is done in the COM module (BSW Modules > Com Stack > COM). First ComSignals must be created for transmitting and receiving. These will reference the ISignals that were created in step one. Note also that the RX ComSignal has callbacks defined, this is so that the RTE can be alerted when the COM module receives data from the signal.

Next ComPdus must be created for each direction, these will reference the PDUs created in the EcuC module. The RX ComPdu should reference the PDU which handles PduR → COM, and the TX ComPdu should reference the PDU which handles COM → PduR. The TX Pdu also requires the ComTXPdu configuration element with TxModeTrue selected, and with a valid ComTxMode defined (in this case: DIRECT).

After the ComPdus have been created the RTE and BSW will be linked and the PDUs should now be routed through the BSW modules. First a PduRoutingPath must be created for each direction, (Can be found in the PduR module: BSW Modules > Com Stack > PduR). The routing path should route from one PDU (The PDUs that were created in the EcuC module) to another (Com2PduR → PduR2SoAd for transmitting, or SoAd2PduR → PduR2COM for receiving). This could look like below:

Two of the three BSW modules which handle PDUs have now been configured (COM & PduR). The Socket Adaptor (SoAd) should now be configured. This module routes a PDU to/from a socket connection, which can be configured to use a certain protocol or port, or to only receive messages from a certain IP Address (as shown in previous parts of the Application Note). There are two types of routing that the Socket Adapter uses, a PduRoute (which handles routing from a PDU to a Socket when transmitting data) and a SocketRoute (which handles routing from a Socket to a PDU when receiving data). Before these routes can be defined, a SocketConnection must be created. SocketConnections are stored in SocketConnectionGroups, and it is possible to either create a new group, or to use a previously existing one if it meets the use case. In this case a new group has been created.

In this example the SocketConnection is set up so that it expects to receive messages from the server 192.168.1.1:20 and will transmit from 192.168.1.10:555.

Once the SocketConnectionGroup and SocketConnection have been created, the data can be routed. The PduRoute will need a reference to the srcPdu (The PduR2SoAd PDU created in the EcuC module) and a reference to the SocketConnection or SocketConnectionGroup.

The SocketRoute will need a reference to the SocketConnection or SocketConnectionGroup and also a reference to the DestPdu (SoAd2PduR pdu). 

Step 3. ASW Configuration

This step will involve specifying how the software component will communicate using PPorts and RPorts, and creating a Runnable Entity which will process the data.

First we will create a PPort and RPort for both the MasterSWC and the TesterSWC. As the packet will have four bytes of data, a uint32 will be used as the SenderReceiverInterface.

Once the ports have been created they should be connected. Open the TopLevelComposition with the Composition editor and create the connections between the SWCs using the Manual Connection Editor.

To create a runnable, open the MasterSWC in the component editor and navigate to the functions tab. Take note of the function name, as this will be the name of the method that needs to be implemented in the ASW code later on.

In order to allow the SWC to read and send the data over ethernet DataAccessPoints need to be configured. In this example a DataReceivePointByArgument will be used for the RPort and a DataSendPoints will be used for the configured PPort. 

Once the runnable has been created with the correct DataAccessPoints, navigate to the events tab and create a new DataReceivedEvent. This should reference the runnable that was created previously and also the datatype of the RPort that the MasterSWC is using.

Now the DataReceivedEvent must be mapped to an OS Task. This can be done in the RTE Mapping Editor (using either the RTE BSW Configuration Container or the EcucValueCollection Container). The event will be in the unmapped entities table and should be dragged onto the OS Task that it should be a part of.

Step 4. Final System Configuration

Finally, open the System Data Mapping Editor for the top-level System and update the relevant SenderReceiverToSignalMapping.

Identify the new SenderReceiverToSignalMapping without a mapped SystemSignal, and update it with the relevant SystemSignal created in Step 1.

Once this is complete, the ECU Extract should be updated. Right click on the System container and choose the Create ECU Extract tool, ensuring the 'Update existing ECUExtract' option is selected.

Code generation should now be run for the BSW, RTE, and OS.

Step 5. Writing the ASW code

Now that everything has been configured and all the code has been generated, code must be written to handle the new Ethernet signal.

Using the name of the function specified in Step 3 when creating the runnable we can write a function using the APIs that the RTE generated to handle the RPorts and PPorts of the MasterSWC.

To add the function, navigate to MasterSWC.c and write the following code:

Once the code has been written the Starter Kit can be built and if tested using EthMaster the ECU should subtract one from the data it receives and reply. It should be using the ports specified during the BSW configuration (20 For Server and 555 For ECU).