SOME/IP in depth · Bhargava Mandapati

— Scalable service-Oriented MiddlewarE over IP — is how vehicle services actually talk over Ethernet. If is the idea, SOME/IP is the mechanism most of the industry chose to implement it.

The four mechanisms#

What SOME/IP provides — Discovery finds the service. Methods are requests with answers. Events are pushed notifications. Fields combine a value with get, set and notify.

Service discovery#

A client does not know where a service lives. It asks.

Discovery, conceptually

Client  →  multicast:  "who offers SeatService, service id 0x1234, version 1.x?"
Server  →  unicast:    "I do — at 192.168.1.20:30501, version 1.2"
Client  →  server:     subscribe / call

Methods — requests with answers#

A method call

Client → Server:  setPosition(seat = ROW1_LEFT, position = 42)
Server → Client:  ok
              or  error: BLOCKED

Methods can also be fire-and-forget — no response expected — which is the right choice for anything where the answer would be ignored anyway.

Events — pushed notifications#

The server sends to subscribed clients when something changes. Subscription is per-event-group, not per-event, so related notifications are managed together.

Fields — a value with three operations#

A field is a value that supports get, set and notify. It is the closest thing to a traditional signal, which makes it the natural landing place for migrated CAN signals.

Interfaces are described, not hand-written#

Interfaces are defined in an IDL — commonly Franca IDL, or ARXML in an AUTOSAR toolchain — and code is generated for both ends.

A Franca interface definition

package com.oem.vehicle
 
interface SeatService {
    version { major 1 minor 2 }
 
    attribute UInt8 massageIntensity          // a field: get, set, notify
 
    method setPosition {
        in  { UInt8 seatId  UInt8 position }
        out { Boolean accepted }
        error { INVALID_SEAT BLOCKED NOT_AVAILABLE }
    }
 
    broadcast occupancyChanged {              // an event
        out { UInt8 seatId  Boolean occupied }
    }
}

The decisions that determine whether it lasts#

Version explicitly, from the first message. Major and minor, with defined compatibility rules.

Errors are an enum, not a boolean. A boolean can only say "no". An enum can say why, and can gain values.

Append only. New methods and fields go at the end. Reordering breaks generated code on the other end.

Do not pack values to save bytes. Ethernet has bandwidth. Packing costs you the ability to change a range later.

Design for the service being absent. On a cheaper trim it will not exist.

Practical concerns#

Serialisation is not free. Every call is packed and unpacked. High-frequency data over SOME/IP costs measurable CPU — which is one reason continuous sensor streams often use instead.

Multicast for discovery needs network configuration. Discovery traffic uses multicast, and switch configuration must permit it. A service that is offered but never discovered is very often a multicast configuration problem, not a code problem.

Timing is not guaranteed by SOME/IP itself. It relies on the network. If timing matters, that is a concern underneath.

Debugging

# Capture and dissect — Wireshark understands SOME/IP
tcpdump -i eth0 -w some-ip.pcap
 
# Is the service being offered at all?
tcpdump -i eth0 'udp port 30490'   # the usual service discovery port

Next#

The other major protocol, and when it is the better choice.