¹ No values in the receive buffer

For test steps such as read event, ecu.test only looks in the receive buffer and does not wait for new values. The values must therefore already be there, otherwise the result is ~NotPresent~ or an old value. Receipt and deserialization must have taken place by the time the values are in the receive buffer. Deserialization takes a while for very extensive signal structures. Receipt requires that SOME/IP-SD communication has been successfully carried out (active) or read (passive), i.e. SOME/IP-SD Find and Offer must have taken place for the relevant service and SOME/IP-SD Subscribe and SubscribeAck for the relevant event group. The event is usually sent cyclically by the DUT, so the cycle time should also be waited for.

² Wait until true with a sufficiently large timeout

The size of the timeout depends mainly on the factors described in ¹ and can be chosen very generously for the first attempts (10 seconds or even longer). A polling cycle of e.g. 100ms is also recommended in order to reduce access to the receive buffer and the associated round trips (especially when using the Tool-Server).

³ .pcap/.pcapng

The recording of ethernet communication as a .pcap or .pcapng file. It can be created either in ecu.test (e.g. with a SERVICEACCESS - RECORDING-PCAP port) or externally with tools such as Wireshark. It is important to ensure that the complete communication of the entire test case execution is included. This also applies to port start and pre-process. If in doubt, the recording should be started with Wireshark before pressing the play button for the test case execution.

⁴ Must be ensured

Because ecu.test cannot actively communicate via a passive port (e.g. no SOME/IP-SD Subscribe, no SOME/IP method call, etc.), the DUT must be stimulated by another participant. If this is not available, the relevant communication cannot usually be monitored and evaluated with ecu.test. Please also ask yourself: is a passive port the right choice for the use case to be mapped or should it have been an active port instead?

⁵ GetActiveServices job

This job can be used at the start of a test case, for example, to wait until ecu.test knows the offering endpoints for the services required in the test case or signal acquisition. Specifically, a tuple (ServiceId, InstanceId) appears in the job results list as soon as ecu.test has received and processed the corresponding SOME/IP-SD offer packet.
ATTENTION: The job does not deliver all services offered in the network, but only those required by ecu.test in the current package.
ATTENTION: The job does not wait for the SOME/IP-SD Subscribe/SubscribeAck and also not for the receipt of the associated events, so that an event read executed directly after the GetActiveServices job with wait-until-true can still deliver ~NotPresent~.

⁶ Is an event sent? / Is there a method call?

To be able to check this in Wireshark (e.g. after directly recording or loading a .pcap or .pcapng file), a display filter of this type should be set: someip.serviceid==0x1234 && someip.methodid==0x5678 where the value 0x1234 must be replaced by the information from the service tab of ecu.test (tooltip of the corresponding service) and the value 0x5678 (tooltip of the corresponding method or event). The event is sent if Wireshark displays the MessageType 0x02 (Notification) in the packets found. A method call, on the other hand, can be recognized by MessageType 0x00 (Request).
NOTE: If the display filter does not return anything, Wireshark may still need to be configured for SOME/IP. To do this, right-click on a UDP packet with port 30490 and in the context menu > Decode as... > in the dialog under "Current" then select "SOME/IP", save and OK.

⁷ Correct network adapter/connection selected? Are the network and controller correct?

The aim here is to check whether the correct "physical layer" has been selected. If the DUT is connected to a completely different port, it is not possible to communicate with it. This mainly concerns the PCAP ports of the TraceTronic: Ethernet tool, but also Ethernet ports for Vector: XL-API and Vector: SIL-Kit. A simple test is to create a RECORDING-PCAP port in the TBC and enter the same network adapter/connection/network+controller, path/filename for PCAP/PCAPNG file e.g. C:\temp\recording.pcapng, empty BPF filter and VLAN setting "no tagging". Set the start behavior of the port to "Always" and simply execute a test case with a wait test step (e.g. 30 seconds).
The recorded file should contain parts of the communication you are looking for (e.g. SOME/IP events of the DUT). If not, other network adapters/connections/network+controller names should be tried.

⁸ Special tests for Vector: SIL-Kit

Is the sil-kit-registry.exe running and accessible from the test bench computer under the specified registry URI? Does the path to SilKit.dll (or libSilKit.so under Linux) match the path specified in the TBC? Is the 64-bit version of the SIL kit used? Unfortunately, you cannot query the names of the network and controller from the SIL kit, but must enter them exactly as they appear in the TBC. Typing errors may have crept in here.

⁹ VLAN settings suitable for the network

If the TBC option allows the "auto" setting, the VLAN ID from the .arxml is used. Depending on the network configuration, however, the setting may not be suitable - e.g. if the network driver already checks and removes the VLAN header of received packets or adds it to outgoing packets. If in doubt, a test recording of the network traffic can be carried out as in ⁷ and the VLAN tags in the resulting .pcapng file can be analyzed with Wireshark. In Wireshark, the corresponding section in the packet analysis is called "IEEE 802.1Q Virtual LAN". If there is no corresponding entry in any packet, "disable" can be entered as the VLAN setting in the TBC - or if there is only the "VLAN ID" field, a 0.

¹⁰ ping, telnet, ssh

Depending on which interfaces the DUT offers - e.g. whether it responds to ICMP echo requests (a.k.a. ping) at all, etc. If the DUT can be reached in this way, the SERVICEACCESS - SERVICE port (without PCAP) can be used, otherwise a SERVICEACCESS - SERVICE-PCAP port should be used. If no firewall rules prevent the ping/telnet/ssh attempts, it is normally quite easy to predict from the IP addresses of the DUT and test bench computer and the subnet mask used whether the DUT can be reached by operating system means or not.

¹¹ IP address must not correspond to one that...

already belongs to another participant, e.g. another ECU in the test bench setup.
Especially for tool tracetronic: Ethernet: No IP address may be entered that the operating system has assigned for this network adapter. This would lead to a collision of network stacks, which is usually indicated by a large number of "ICMP port unreachable" or "TCP RST" packets in the recording.

¹² Same subnet

Assuming the DUT has the IP address 192.168.123.42 and the subnet mask is 255.255.255.128, all IP addresses from 192.168.123.1 to 192.168.123.127 would be eligible for ecu.test - with the exception of 42, as this is already used by the DUT. A last byte >= 128 or other values in the first 3 bytes are excluded by the subnet mask.
If the DUT and ecu.test are in different subnets, no (IP) communication can take place between them.

¹³ Please note when using PCAP-based ports

Please use npcap (https://npcap.com/windows-10.html) and completely remove any existing WinPCAP installation. WinPCAP is hopelessly outdated. A parallel installation leads to unexpected behavior.