SOME/IP
Reboot detection
An ECU that restarted has forgotten every subscription. Its partners must notice that quickly, even when its OfferService entries never stopped for long. Two values in every SD message make this possible: a flag that marks a recent restart, and the Session ID.
Reboot flag and Session ID
Every SD message carries a Session ID in its SOME/IP header and a reboot flag (a flag in the SD header: "I restarted recently") in its flags. The Session ID goes up by one with every SD message. After a restart it starts at 1 with the reboot flag set to 1; the flag stays 1 until the Session ID has wrapped around once. From then on the flag is 0.
The rule
Reboot detection (noticing that a partner restarted) compares each new SD message with the last one received from the same sender. A reboot is detected if either is true:
case 1
The reboot flag came back
The last message had reboot flag 0; this one has 1.
case 2
The Session ID went backwards
Both messages have reboot flag 1, and the new Session ID is not larger than the old one.
Checking only the Session ID is not enough: messages can be lost, so after a reboot the Session ID may already be higher than the last value received. The reboot flag catches that case.
Session IDs are kept per communication relation (one sender and one receiver), and separately for multicast and unicast SD messages. So each partner judges each sender on its own.
What happens after a reboot is detected
The rebooted ECU has lost its state. Its partners act on that: a client that detects a reboot of its server treats its subscriptions as gone and sends a new SubscribeEventgroup with the Initial Data Requested flag set, so it gets the initial events again; a server that detects a reboot of a client replaces that client's old subscription with the new one.
When the IP address is lost
When an ECU loses its link or its IP address, Sd leaves all phases. A server sets its event handlers to RELEASED: nobody is subscribed any more. A client reports its client services and consumed eventgroups as DOWN. When TcpIp reports the IP address as assigned again, everything starts again with the Initial Wait Phase. In the example of the SOME/IP-SD specification, an ECU whose link went down also starts its Session ID again at 1 with the reboot flag set, so its partners detect a reboot and clean up as well.
Try it
The radar sends SD messages to the brake ECU. Here the Session ID wraps after 8 so you can see it happen. Send, lose, reboot, and watch the result of reboot detection on the brake ECU.
Radar now: Session ID – · reboot flag –
| Received Session ID | Reboot flag | Last received | Result |
|---|
Things to notice. Send nine SD messages: at the wrap-around the Session ID drops from 8 to 1, yet no reboot is detected, because the reboot flag went to 0. After that, reboot the radar and lose its first two SD messages: the full rule still detects the reboot (the reboot flag came back), the Session-ID-only rule misses it.
Check yourself optional
New terms in this lesson
| Term | Meaning |
|---|---|
| reboot flag | Flag in the SD header: 1 after a restart until the Session ID wraps around for the first time |
| reboot detection | Noticing that a partner restarted: its reboot flag goes from 0 to 1, or its Session ID goes backwards while the flag is 1 |
| communication relation | One sender and one receiver; Session IDs and reboot flags are judged per relation, separately for multicast and unicast |
Source: SOME/IP-SD Protocol Specification, R20-11, sections 4.1.2.1, 4.1.2.2 (reboot flag and detection), 4.1.4.3 and 4.1.6 (link loss examples); Service Discovery, R20-11, sections 7.6 and 7.7 (reaction to a lost IP address).