SOME/IP in AUTOSAR Classic

SOME/IP

Server and client

For each service instance, one ECU is the server and others are clients. Each role comes with its own duties, from power-up to shutdown.

Two roles, one service instance

The radar ECU is the server of radar instance 1: it sends OfferService and answers FindService, serves Eventgroup 1 through its event handler and provides the methods Calibrate and Adjust. The brake ECU is a client: it wants radar instance 1, subscribes to Eventgroup 1 as a consumed eventgroup and calls Calibrate. Arrows between them: OfferService and FindService, SubscribeEventgroup, SubscribeEventgroupAck, Notification, REQUEST and RESPONSE. Radar ECU · server offers radar instance 1OfferService, answers FindService event handlerEventgroup 1 · keeps the subscribers provides Calibrate, Adjustruns the methods Brake ECU · client wants radar instance 1FindService if needed consumed eventgroupEventgroup 1 · subscribes, renews calls Calibratewaits for the RESPONSE OfferService · FindService SubscribeEventgroup SubscribeEventgroupAck Notification REQUEST RESPONSE
Figure 1. Read across each row: every duty on one side has a partner duty on the other. The pink arrows are Service Discovery, the next part of the course.

Roles belong to a service instance, not to an ECU. The brake ECU of this example is the client of the radar and, at the same time, the server of its own brake service.

The duties

Both roles talk through Sd, the subject of the next part. A few SD entries carry most of it: OfferService (from the server: "this service instance is available here", valid for a TTL, a time to live, and repeated), FindService (from the client: "who offers this service?"), SubscribeEventgroup (from the client: "send me the events of this eventgroup"), answered by SubscribeEventgroupAck (accepted) or SubscribeEventgroupNack (refused), and StopOfferService (the service instance is no longer available).

server

Offer and serve

Send OfferService while the service instance is available, answer FindService, accept or refuse each SubscribeEventgroup, send events only to subscribers (and the initial event of each field to each new subscriber), answer each REQUEST, and send StopOfferService when going away.

client

Find and use

Send FindService when the service is needed and not yet known, subscribe to the wanted eventgroups and renew the subscriptions, open the TCP connection if the service uses TCP, call methods and handle timeouts, and drop everything when the server sends StopOfferService.

Note the one duty that is easy to miss: if a service instance uses TCP, it is always the client that opens the connection, before subscribing, and the client that closes it.

From power-up to shutdown

Moment and messagesRadar ECU (server)Brake ECU (client)
1 · Power-up
nothing is sent yet		Waits. It may offer only when its IP address is assigned and BswM has set the service to AVAILABLE.Waits. It may send FindService only when its IP address is assigned and BswM has set the client service to REQUESTED.
2 · Start
OfferService FindService by multicast		After a short random wait it sends OfferService "radar instance 1, reach me here", and repeats it from then on.Nothing is known about the radar yet, so after a short random wait it sends FindService "who offers the radar service?".
3 · Found
OfferService by unicast		It receives the FindService and answers with an OfferService sent directly to the brake ECU.It receives the OfferService, learns the radar's address and stops sending FindService. If the service used TCP, it would open the connection now.
4 · Subscribe
SubscribeEventgroup SubscribeEventgroupAck initial event		It checks the SubscribeEventgroup, adds the brake ECU to the subscribers of Eventgroup 1, sends SubscribeEventgroupAck, and sends the initial event of each field in the eventgroup to the brake ECU.It wants Eventgroup 1 and sends SubscribeEventgroup, telling the radar where to send the events.
5 · Running
NOTIFICATION REQUEST RESPONSE		It sends events to every subscriber and answers REQUESTs.It receives events and calls methods, waiting for each RESPONSE with a timeout.
6 · Renewal
OfferService SubscribeEventgroup SubscribeEventgroupAck		It keeps sending OfferService at its regular pace. A subscription that is not renewed expires when its TTL runs out.It answers each OfferService by renewing its subscription, so it never expires.
7 · Shutdown
StopOfferService		The service is going away. It sends StopOfferService and forgets all subscriptions.It receives the StopOfferService, forgets its subscriptions and the service, and sends no FindService; it waits for a new OfferService.

How AUTOSAR names the two sides

The Sd module of an ECU keeps one configuration container per service instance and role. An SdServerService (one service instance this ECU offers as server) lists its event handlers (the server side of an eventgroup, which keeps the subscribers) and the methods it provides. An SdClientService (one service instance this ECU uses as client) lists its consumed eventgroups (the client side of an eventgroup, which subscribes) and the methods it calls.

Things to notice. The server never needs to know in advance who its clients are; it learns them from each SubscribeEventgroup. The client never needs to know the server's address in advance; it learns it from the OfferService.

Check yourself optional

New terms in this lesson

TermMeaning
server, clientThe roles for one service instance: the server provides it, clients use it
SdServerServiceSd container for a service instance this ECU offers
SdClientServiceSd container for a service instance this ECU uses
event handlerServer side of an eventgroup: keeps its subscribers
consumed eventgroupClient side of an eventgroup: the one it subscribes to

Source: SOME/IP-SD Protocol Specification, R20-11, sections 4.1.4, 4.1.6 and 6.2 (server and client behaviour); SOME/IP Protocol Specification, R20-11, section 4.2.1.2 (TCP opened by the client); Service Discovery, R20-11, section 7.1.