SOME/IP in AUTOSAR Classic

SOME/IP

OfferService and the TTL

A server makes each service instance known with an OfferService: a statement of where the instance can be reached and for how long the statement stays valid. Clients trust it only until that time runs out, so the server keeps renewing it.

Entries and options

Sd has its own messages. A SOME/IP-SD message (a SOME/IP message of the Service Discovery service, Service ID 0xFFFF) travels over UDP (the connectionless transport, lesson 22) to a fixed port, 30490 by default. It goes either by multicast (once to a group address that every listening ECU receives) or by unicast (to one ECU at its own IP address). One SD message carries a list of entries (single statements, such as "this service instance is offered") and a list of options (additional information an entry points to). Each entry names the options it needs.

The entry a server uses is the OfferService (the statement "this service instance is available, for TTL seconds"). Where to reach the instance is in its Endpoint options (an IP address, a port and UDP or TCP).

A SOME/IP-SD message: a SOME/IP header with Service ID 0xFFFF, Method ID 0x8100 and Message Type NOTIFICATION, the SD flags, a list of entries and a list of options. The entry OfferService for radar instance 1, major version 1, TTL 3 s points to two Endpoint options: UDP and TCP, each with IP address and port. SOME/IP header · Service ID 0xFFFF · Method ID 0x8100 · NOTIFICATION flags: reboot flag and others (lesson 16) entries OfferService · radar instance 1major version 1 · TTL 3 s · options 1–2 OfferService · brake instance 1 … options option 1 · Endpoint option · UDP192.168.0.10 · port 30501 option 2 · Endpoint option · TCP192.168.0.10 · port 30501 one SD message, many entries: Sd packs whatever can go out at the same time
Figure 1. Follow the two pink arrows: the entry only names radar instance 1; the options say where. A server serves a service instance over UDP, TCP or both, so an OfferService points to one or two Endpoint options.

The Endpoint options of an offer are not just for method calls. The server also sends its events from exactly these addresses and ports, so a client knows where the events of this service instance come from.

The TTL

Every OfferService carries a TTL (time to live: how many seconds the offer stays valid unless renewed). A client counts the service instance as available only while the TTL runs. The server sends a new offer before the old TTL ends, and each one starts the TTL again. If the offers stop, for whatever reason, the TTL runs out and clients drop the service instance on their own. This makes an offer soft state (state that disappears by itself unless renewed in time); the TTL works like a lease.

Timing diagram: OfferService every 2 seconds with TTL 3 seconds; the TTL periods overlap. After the server crashes at 7 seconds, the last TTL ends at 8 seconds and the client counts the service instance as gone. OfferService server crashes TTL at client client sees available gone 0 s12 s8 s: last TTL ends
Figure 2. Each pink bar is one TTL of 3 s, starting at an OfferService. The bars overlap, so the service instance never looks gone while offers keep coming. After the crash nothing renews the last bar, and the client drops the service instance when it ends.

normal end

StopOfferService

A server that shuts a service instance down sends a StopOfferService (the OfferService entry with TTL 0). Clients drop the service instance at once.

special TTL

"Until reboot"

The highest TTL value means "valid until the next reboot". Then nothing expires on its own, and the server need not repeat its offers; reboot detection (noticing that a partner restarted, lesson 16) takes over.

why a TTL

No goodbye needed

A crashed ECU or a broken cable cannot send a StopOfferService. With a TTL, the rest of the network still notices.

Try it

The radar sends an OfferService every 2 seconds. Pick a TTL, start the clock, then break things: lose one offer, crash the server, or stop properly.

Things to notice. A TTL shorter than the repeat makes the service instance flicker between available and gone. One lost OfferService does no harm when the TTL is longer than the repeat. After a crash the client needs up to one TTL to notice. With "until reboot" a crash is never noticed this way; the StopOfferService still works.

Check yourself optional

New terms in this lesson

TermMeaning
SOME/IP-SD messageA SOME/IP message of the Service Discovery service (Service ID 0xFFFF); it carries entries and options
entryOne statement inside an SD message, such as an OfferService
optionAdditional information an entry points to, such as an Endpoint option
Endpoint optionIP address, port and UDP or TCP: where to reach a service instance
OfferServiceServer: "this service instance is available here, for TTL seconds"
StopOfferServiceThe OfferService entry with TTL 0: no longer available
TTLTime to live: how many seconds an offer stays valid unless renewed; 0 means stop
multicastSent once to a group address; every listening ECU receives it
unicastSent to one ECU only, at its own IP address
soft stateState that disappears by itself unless renewed in time

Source: SOME/IP-SD Protocol Specification, R20-11, sections 4.1.2 (message, entries, options), 4.1.2.5 (offer and stop offer), 4.1.2.6 (endpoints), 4.1.3 and 4.1.4.5 (soft state).