SOME/IP in AUTOSAR Classic

SOME/IP

Events

An event is a one-way message from the server to every client that subscribed to its eventgroup. Nobody answers it.

How an event travels

The radar server sends a NOTIFICATION of BrakeEvent to two subscribers, the brake ECU and the display ECU, and none to the seat ECU, which is not subscribed. No message comes back. Radar (server) Brake ECUsubscriber Display ECUsubscriber Seat ECUnot subscribed NOTIFICATION · BrakeEvent same NOTIFICATION receives nothing
Figure 1. Arrows only point down: the event goes from the server to its subscribers, and nothing comes back. The seat ECU never sees the message.

On the wire an event travels with the Message Type NOTIFICATION. A receiver never sends a response and never sends an ERROR back for an event, even if it cannot read it. Each client that receives it is a subscriber (a client whose subscription to the eventgroup is currently accepted). Subscribing is the job of Service Discovery (lesson 14); this lesson only looks at the event itself.

When does the server send?

SOME/IP itself does not say when an event is sent. The specification names three common strategies:

at a fixed period

Cyclic update

A cyclic update (sent at a fixed period, changed or not) carries the current value, for example every 100 ms. Good for safety-related values the receiver watches.

on every change

Update on change

An update on change (sent only when the value changes) goes out as soon as the value changes, for example "door opened".

on a large change

Epsilon change

An epsilon change (sent only when the value changes by more than a set amount) skips the small steps since the last send.

Timing diagram over 12 seconds: a value line, and below it the send times for three strategies: cyclic update every second, update on change, and epsilon change for a change of more than 5. value cyclic update (1 s) update on change epsilon change (> 5) 0 s12 s
Figure 2. Same value, three strategies. Count the dots: 11 sends with the cyclic update, 12 with update on change, 4 with epsilon change. Epsilon change misses the small steps but catches every jump.

The receiver cannot tell which strategy the sender uses; a NOTIFICATION looks the same either way. One server can even mix strategies for one event. In the Classic Platform the sending side decides, through when the SWC writes the value and how the transmission of the PDU is configured below the RTE.

Optional: the Session ID of an event

An event has no client, so the Client ID in the Request ID is 0. With session handling on, the Session ID counts each NOTIFICATION, so a receiver can spot gaps; with session handling off it stays 0 for this event.

Try it

The radar measures a distance that changes now and then. Choose a strategy, choose which clients are subscribed, and press "Start". You can change the subscriptions while the clock runs.

Things to notice. The value lane is the same every run; only the NOTIFICATION lane changes with the strategy. A client that is not subscribed gets nothing, and a client that subscribes in the middle only gets events from then on: a plain event does not repeat the old value for a new subscriber (a field does: its initial event, the current value sent once to a new subscriber, lesson 8).

Check yourself optional

New terms in this lesson

TermMeaning
subscriberA client whose subscription to an eventgroup is currently accepted; it receives the events
cyclic updateAn event sent at a fixed period, whether or not the value changed
update on changeAn event sent only when the value changes
epsilon changeAn event sent only when the value changes by more than a set amount

Source: SOME/IP Protocol Specification, R20-11, sections 4.2.4 (notification events, sending strategies) and 4.2.6.2 (no error messages for events).