SOME/IP in AUTOSAR Classic

SOME/IP

Subscribing to an eventgroup

A client asks for the events of a group by subscribing to it, in reply to an OfferService. The server accepts or refuses, and the subscription holds only for its own TTL, so the client renews it with every offer.

A client that wants the events of a service does not just listen. It subscribes to an eventgroup (a set of events and fields the server publishes together, identified by an Eventgroup ID). It does so with a SubscribeEventgroup entry (the request "please send me the events of this group"), and the server answers with a SubscribeEventgroupAck (accepted) or a SubscribeEventgroupNack (refused). Only after the Ack do events flow.

The basic exchange

Sequence: the radar sends OfferService by multicast; the brake ECU sends SubscribeEventgroup for Eventgroup 1 with TTL 3 seconds, Initial Data Requested and an Endpoint option; the radar checks it and sends SubscribeEventgroupAck, then the initial event of the field UpdateRate, then the event BrakeEvent whenever it occurs. Brake ECU (client) Radar ECU (server) OfferService · radar instance 1 · multicast SubscribeEventgroup · Eventgroup 1 · TTL 3 sInitial Data Requested · Endpoint option: client IP and port checks the request SubscribeEventgroupAck · Eventgroup 1 · TTL 3 saccepted Notification · UpdateRate = 20initial event: the field's current value Notification · BrakeEventsent when it occurs pink: SOME/IP-SD · orange: events
Figure 1. Three pink SD entries set up the subscription; only then do orange events flow. The field's initial event comes right after the Ack; the event BrakeEvent comes only when it next occurs.

client → server

SubscribeEventgroup

Names the service instance (Service ID, Instance ID, major version) and the Eventgroup ID. Carries a TTL (how long the subscription holds), the client's Endpoint options (its IP address and port for events over UDP and/or TCP), and the Initial Data Requested flag when it wants the current field values.

server → client

SubscribeEventgroupAck

Repeats the Eventgroup ID and the TTL. If the events of this eventgroup are sent by multicast, the Ack carries a Multicast option (the group address the client must listen on).

server → client

SubscribeEventgroupNack

The Ack entry with TTL 0. Reasons: unknown eventgroup, a TCP connection the eventgroup needs is not open, a problem with the Endpoint options, or no resources left.

All four eventgroup entries (Subscribe, StopSubscribe, Ack, Nack) go by unicast directly between the two ECUs, never by multicast. One SD message can carry Subscribe entries for several eventgroups at once.

The subscription has a TTL too

Like an OfferService, a subscription is soft state (it disappears unless renewed): it holds only for its TTL. The client keeps it alive by sending a new SubscribeEventgroup in reply to every cyclic offer of the Main Phase. A renewal does not bring the initial events again; the client already has the values. If renewals stop, the server removes the subscriber when the TTL runs out.

Both sides track the result. On the client, Sd reports the consumed eventgroup as AVAILABLE once the Ack arrives. On the server, the event handler becomes REQUESTED with its first subscriber (lesson 17).

Initial events: when they are sent

An initial event is the current value of a field, sent once so a new subscriber does not wait for the next change.

SituationInitial events sent?
First Subscribe, Initial Data Requested setYes, right after the Ack, by unicast to this client only
Renewal of a subscription that is still validNo
Previous Subscribe got no Ack, client subscribes againYes: the client sets Initial Data Requested again
Events in the eventgroup that are not fieldsNever; a pure event has no current value

Stopping and retrying

client

StopSubscribeEventgroup

When the events are no longer needed, the client sends the Subscribe entry with TTL 0. No answer comes back. The server stops sending to it; if it was the last subscriber, the event handler becomes RELEASED.

client, optional

Subscribe retry

If neither Ack nor Nack arrives within SUBSCRIBE_RETRY_DELAY, the client sends the Subscribe again without waiting for the next offer, up to SUBSCRIBE_RETRY_MAX times. Useful when offers are far apart.

Try it

Pick a story and step through it.

Things to notice. Every SubscribeEventgroup is a reply to an OfferService; the offers drive the rhythm. A lost Ack costs nothing lasting: at the next offer the client simply subscribes again and sets Initial Data Requested once more. A Nack for a missing TCP connection makes the client check and reopen that connection.

Check yourself optional

New terms in this lesson

TermMeaning
SubscribeEventgroupClient to server: "send me the events of this eventgroup, for TTL seconds, to these endpoints"
SubscribeEventgroupAckServer to client: subscription accepted
SubscribeEventgroupNackServer to client: subscription refused (the Ack entry with TTL 0)
StopSubscribeEventgroupThe Subscribe entry with TTL 0: events no longer wanted; no answer
Initial Data Requested flagIn the Subscribe: "send me the current values of the fields"
Subscribe retryOptional resend of an unanswered Subscribe (SUBSCRIBE_RETRY_DELAY, SUBSCRIBE_RETRY_MAX)
consumed eventgroup AVAILABLE / DOWNClient side: subscription acknowledged / not
event handler REQUESTED / RELEASEDServer side: at least one subscriber / none

Source: SOME/IP-SD Protocol Specification, R20-11, sections 4.1.3.1 (eventgroup entries) and 4.1.6 (publish/subscribe, initial events, retry); Service Discovery, R20-11, sections 7.2.5, 7.6.2, 7.6.3 and 7.7.4.