[SOME/IP] General Troubleshooting

Owned by Michael Kobert
Last updated: May 03, 2024
7 min read

Issue

The following article guides you through different kind of use cases with SOME/IP.

Solution

For example:

  • reading a leaf node (ServiceEventLeaf-Read)

  • whole event (ServiceEvent-Read event)

  • as an event of a service

  • as a notifier of a field

 

If you receive a ~NotPresent~ it may be due to there are no values in the receive buffer1. Please take a look at the flow chart:

grafik-20240202-090725.png

If your symptom is not listed please take a look at #support.

For example:

  • ServiceMethod-Execute

 

If you receive the following error

PortInitMethod() failed: InitMethod

please check, that the port must not be SERVICEACCESS - SERVICE-PCAP-PASSIVE.

If you receive ~NotPresent 'the service is not ready'~ or the following error

PortExecuteMethod() failed: ... error code 4 (the service is not ready)

it means, that ecu.test does not yet know which endpoint offers the service (SOME/IP-SD Offer not received). Please take a look at the flow chart:

grafik-20240202-090825.png

If your symptom is not listed please take a look at #support.

For example:

  • ServiceMethod-Read parameters

  • ServiceMethod-Read return values

 

If you receive one of the following errors

PortInitMethodParameter() failed: Passive reading of method parameters is not supported ...

please check, that the used port has to be SERVICEACCESS - SERVICE-PCAP-PASSIVE.

 

If you receive a ~NotPresent~, please take a look at the flow chart:

If your symptom is not listed please take a look at #support.

For example:

  • Leaf node of events

  • Method parameters

  • Method return values

 

If you receive no samples, please take a look at the flow chart:

If your symptom is not listed please take a look at #support.

Please contact us via support@tracetronic.com or send us your request via support.tracetronic.com.

Please take a look at [Request] The perfect support request as well.

Necessary data would be in this case:

  • test report (.trf)

  • corresponding ecu.test log files (ecu.test_err.log and ecu.test_out.log)

  • corresponding package (.pkg) and/or project (.prj)

  • ecu.test configuration files (.tbc and .tcf)

  • corresponding bus database (.arxml)

  • matching Wireshark recording (.pcap or .pcapng)3

1 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.

2 Wait until true with a sufficiently large timeout

The size of the timeout depends mainly on the factors described in 1 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).

3 .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.

Legal Notice | Privacy Policy