SOME/IP

The Sd configuration map

The configuration of the Sd module mirrors the Service Discovery part of this course: one container per network, timers for the phases, and one container per service instance with its eventgroups and the socket connections and routing groups it controls.

The shape of it

Figure 1. Pink is Sd configuration; the dashed arrows are references. Services and eventgroups reference the timers they use above and SoAd's socket connection groups and routing groups on the right; BswM addresses everything through the handle IDs.

per network

SdInstance

An SdInstance (the Sd configuration of one link) exists once per link, including VLANs. It owns the three PDUs for SD messages in SoAd: one to transmit and two to receive (unicast and multicast).

shared

Timers

SdServerTimer (the SD timing of a server) and SdClientTimer (the SD timing of a client) are separate containers. Each service instance and each eventgroup references one; several service instances can share a timer.

per service instance

Server and client services

SdServerService and SdClientService hold the IDs and versions used in the OfferService and FindService entries, the socket connection groups for UDP and TCP, the routing group for methods (in SdProvidedMethods or SdConsumedMethods, the containers for the methods of a service instance), the eventgroups, and a handle ID for BswM.

per eventgroup, server

SdEventHandler

For each event handler, SdEventActivationRef (the routing group Sd enables per socket connection for each subscriber) and SdEventTriggeringRef (the routing group Sd triggers once to send the initial events to a new subscriber), separately for UDP, TCP and multicast.

Two parameters matter everywhere. SdMainFunctionCycleTime (the period of the Sd main function, in seconds) is the step all Sd timing runs on. The HandleId parameters (the numbers BswM uses to request a service instance or eventgroup and to read its state) appear in every server service, client service, event handler, consumed eventgroup and service group.

The map

Every container and parameter of the Sd module, with its multiplicity. Containers are in bold. The chips in "Try it" mark everything that belongs to one feature of the earlier lessons.

Try it

Pick a feature; the map above marks the containers and parameters that set it.

Pick a feature.

Things to notice. Timing is never set on a service instance itself; its SdServerService or SdClientService references a timer. Socket connections and routing groups are never defined in Sd; Sd only references SoAd's socket connection groups and routing groups. Multicast touches both sides: the multicast threshold and the multicast socket connection on the server, the multicast socket connection group and routing group on the client.

Check yourself optional

New terms in this lesson

Term	Meaning
`SdInstance`	The Sd configuration of one link or VLAN, with its three PDUs for SD messages
`SdServerTimer`	SD timing of a server: initial delay, repetitions, cyclic offer delay, TTL, request-response delay
`SdClientTimer`	SD timing of a client: initial delay, repetitions, TTL, request-response delay, Subscribe retry
`SdProvidedMethods` / `SdConsumedMethods`	The methods of a service instance: the routing group Sd enables while it is offered / available
`SdEventActivationRef`	Routing group Sd enables per socket connection for each subscriber
`SdEventTriggeringRef`	Routing group Sd triggers once to send the initial events to a new subscriber
`SdMainFunctionCycleTime`	Period of the Sd main function; all Sd timing runs on it
`HandleId`	The number BswM uses for a service instance, eventgroup or service group

Source: Service Discovery, R20-11, chapter 10 (containers and configuration parameters) and sections 7.2.4, 7.6.5, 7.7.6.