SOME/IP

Sd and BswM: requested and available

Sd does not decide on its own which services to offer or use. BswM tells it which service instances and eventgroups are wanted, and Sd reports back which ones are actually available on the network.

Requested states go down, actual states come up

BswM sets the requested state of each server service (SdServerService), each client service (SdClientService) and each consumed eventgroup. Sd reports the actual state of the client services, the consumed eventgroups and the event handlers back up: AVAILABLE or DOWN (the state as Sd sees it on the network) and, for an event handler, REQUESTED or RELEASED.

Figure 1. Left column down, right column up. Sd acts only when a requested state and an assigned IP address are both there; what it reports up is what it learned from the network.

The requested states (BswM → Sd)

server service

AVAILABLE / DOWN

"The software behind this service instance is ready" or "not ready". AVAILABLE plus an assigned IP address starts the Initial Wait Phase and the offers; DOWN sends a StopOfferService.

client service

REQUESTED / RELEASED

"Some software here needs this service instance" or "no longer". REQUESTED starts a FindService if no valid OfferService is known; RELEASED ends the use.

consumed eventgroup

REQUESTED / RELEASED

Only allowed while the client service is REQUESTED. REQUESTED leads to a SubscribeEventgroup; RELEASED sends a StopSubscribeEventgroup.

Two shortcuts exist. Sd can set a service instance to AVAILABLE or REQUESTED by itself at start-up, and a consumed eventgroup to REQUESTED as soon as its client service is REQUESTED (both configured per service instance). And service instances can be grouped in a service group (a set of service instances that BswM requests or releases together): starting the group makes all its server services AVAILABLE and all its client services REQUESTED at once; a service instance stays so as long as at least one of its started service groups includes it.

The actual states (Sd → BswM)

client service

AVAILABLE / DOWN

AVAILABLE once a valid OfferService arrived and the socket connections (SoAd's links to the server's IP address and port) are ready. DOWN when the TTL of the offer expires, a StopOfferService arrives, the client service is RELEASED, or the IP address is lost.

consumed eventgroup

AVAILABLE / DOWN

AVAILABLE when the SubscribeEventgroupAck arrived and the routing group (a set of routes in SoAd that Sd enables and disables as a whole) for the events is enabled. DOWN again on StopOfferService, TTL expiry, RELEASED, or loss of the IP address.

event handler (server)

REQUESTED / RELEASED

Reported when the first subscriber arrives and when the last one leaves or its subscription TTL expires.

BswM can pass these states on, for example to start or stop SWCs or to request communication. How it does that is decided in BswM's own rules, not in Sd.

Try it

This ECU is a client of the radar service with Eventgroup 1. Change the requested states and let things happen on the network. The two pills show what Sd reports up to BswM.

IP address assigned BswM: client service radar REQUESTED BswM: consumed eventgroup 1 REQUESTED

Reported up: client service radar DOWN · consumed eventgroup 1 DOWN

Things to notice. Requesting the consumed eventgroup before the client service is refused. An OfferService makes the client service AVAILABLE only if it is REQUESTED and the IP address is assigned; otherwise Sd just remembers the offer. The consumed eventgroup needs a SubscribeEventgroupAck before it is reported AVAILABLE. Untick the IP address and everything goes DOWN at once.

Check yourself optional

New terms in this lesson

Term	Meaning
`AVAILABLE` / `DOWN`	Set by BswM for a server service (offer it or not); reported by Sd for a client service (offered or not) and a consumed eventgroup (acknowledged or not)
service group	Service instances grouped in the Sd configuration so BswM can start or stop them together

Source: Service Discovery, R20-11, sections 7.2.1, 7.2.3, 7.6, 7.7 and 7.8.