SOME/IP in AUTOSAR Classic

SOME/IP

Service Discovery timing

The Initial Wait Phase, Repetition Phase and Main Phase of server and client, and every Sd timer that shapes them, on one page.

Server: Initial Wait Phase with a random wait, first OfferService, Repetition Phase with gaps of one, two and four times REPETITIONS_BASE_DELAY, Main Phase with an OfferService every CYCLIC_OFFER_DELAY. Client: Initial Wait Phase, first FindService, FindService with doubling gaps in the Repetition Phase, then Main Phase without FindService. Server Initial Wait Phase Repetition Phase Main Phase · cyclic OfferService 1×2×4×each gap: CYCLIC_OFFER_DELAY Client Initial Wait Phase Repetition Phase Main Phase · no FindService 1×2×4× circles: OfferService · squares: FindService · 1×, 2×, 4×: multiples of REPETITIONS_BASE_DELAY any OfferService ends the client's FindService at once
Timing at a glance. Both sides follow the same shape: a random wait, repetitions with doubling gaps, then the Main Phase. Only the server keeps sending in the Main Phase.

Server timers (SdServerTimer)

The SdServerTimer container of an SdServerService; the PRS constant each parameter sets is named in brackets.

ParameterEffectLesson
SdServerTimerInitialOfferDelayMin / …Maxrandom wait of the Initial Wait Phase before the first OfferService (INITIAL_DELAY_MIN / INITIAL_DELAY_MAX)12
SdServerTimerInitialOfferRepetitionBaseDelayfirst gap of the Repetition Phase; each gap doubles (REPETITIONS_BASE_DELAY)12
SdServerTimerInitialOfferRepetitionsMaxnumber of repeated OfferService entries; 0 skips the phase (REPETITIONS_MAX)12
SdServerTimerOfferCyclicDelayperiod of the OfferService in the Main Phase; 0 = no cyclic OfferService (CYCLIC_OFFER_DELAY)12
SdServerTimerRequestResponseMinDelay / …Maxrandom wait before answering a multicast FindService (REQUEST_RESPONSE_DELAY)13
SdServerTimerTTLTTL of each OfferService, in seconds; 0xFFFFFF = until the next reboot11

Client timers (SdClientTimer)

The SdClientTimer container of an SdClientService.

ParameterEffectLesson
SdClientTimerInitialFindDelayMin / …Maxrandom wait of the Initial Wait Phase before the first FindService13
SdClientTimerInitialFindRepetitionsBaseDelayfirst gap between FindService entries in the Repetition Phase; each gap doubles13
SdClientTimerInitialFindRepetitionsMaxnumber of repeated FindService entries13
SdClientTimerRequestResponseMinDelay / …Maxrandom wait before the SubscribeEventgroup in reply to a multicast OfferService13
SdClientTimerTTLTTL of each FindService and SubscribeEventgroup14
SdSubscribeEventgroupRetryDelay / …RetryMaxSubscribe retry: SubscribeEventgroup again if neither SubscribeEventgroupAck nor SubscribeEventgroupNack arrived (needs SdSubscribeEventgroupRetryEnable in SdGeneral; 0xFF = retry forever)14

Reactions in each phase

InputServerClient
FindService receivedInitial Wait Phase: ignored · Repetition Phase and Main Phase: OfferService (after the REQUEST_RESPONSE_DELAY if the FindService was multicast), repetition counter untouched–
OfferService received–Not Requested: noted with its TTL · Initial Wait or Repetition Phase: no more FindService, on to the Main Phase · Main Phase: TTL renewed, SubscribeEventgroup for each requested consumed eventgroup
StopOfferService received–client service and consumed eventgroups DOWN, socket connections closed, no FindService
TTL runs outthe subscription ends; the event handler is RELEASED if it was the last subscriberclient service DOWN, back to the Initial Wait Phase (FindService again)
BswM: server service DOWN, client service RELEASEDStopOfferService (unless in the Initial Wait Phase), all subscriptions droppedStopSubscribeEventgroup, client service and consumed eventgroups DOWN
IP address lost (ifstatus not up_and_configured)Not Ready; event handlers RELEASEDRequested_but_not_ready if REQUESTED; client service and consumed eventgroups DOWN

Source: Service Discovery, R20-11, sections 7.6, 7.7 and 10.2.7–10.2.8; SOME/IP-SD Protocol Specification, R20-11, section 4.1.4.