Jell AICAN, LIN and FlexRay move signals: a frame carries values at fixed positions, and the network description says which ECU sends which frame. With automotive Ethernet, ECUs can talk in services instead. A service has methods that other ECUs call, events they subscribe to, and fields: values that come with a getter, a setter and a notifier that reports changes. SOME/IP, short for Scalable service-Oriented MiddlewarE over IP, is the AUTOSAR protocol that carries those calls and events.
SOME/IP and its service discovery are part of the AUTOSAR Foundation standard; the details here follow release R24-11. SOME/IP runs over UDP or TCP. Over UDP the payload should stay between 0 and 1400 bytes, and larger messages go over TCP or are split into segments with SOME/IP-TP.
Sixteen bytes of header
Every SOME/IP message starts with the same 16-byte header:
- Message ID, 32 bits: a 16-bit Service ID and a 16-bit Method ID. The recommended practice is to give methods IDs whose first bit is 0 and events IDs whose first bit is 1.
- Length, 32 bits: the number of bytes from the Request ID to the end of the message, so 8 plus the payload.
- Request ID, 32 bits: a Client ID and a Session ID, which together tie a response to its request.
- Protocol Version, which is always 1, Interface Version, the major version of the service interface, Message Type and Return Code, 8 bits each.
The message type tells the receiver what it is looking at: 0x00 REQUEST expects a response, 0x01 REQUEST_NO_RETURN is fire and forget, 0x02 NOTIFICATION is an event, and 0x80 RESPONSE and 0x81 ERROR answer a request. The server copies the Request ID from the request into its response.
Finding services
Before a client can call anything, it has to know where the service runs. SOME/IP Service Discovery, SOME/IP-SD, is itself carried in SOME/IP messages: over UDP, on port 30490, with the Message ID 0xFFFF8100. A server announces each service instance with an OfferService entry, sent by multicast and repeated, so ECUs that start later still find it. A client that wants the service’s events sends a SubscribeEventgroup entry to the server, which answers with a SubscribeEventgroupAck. Every entry has a time to live, and a TTL of 0 withdraws an offer or a subscription. A client can also ask with a FindService entry instead of waiting for the next offer.
Eventgroups
Clients do not subscribe to events one at a time but to eventgroups: logical groups of a service’s events and field notifiers, where every event belongs to at least one group. The server then sends each event only to the ECUs that subscribed, by unicast, or by multicast when the configuration provides a multicast endpoint for the group.
SOME/IP on a test rig
A service-oriented ECU expects its partners to be there: offering the services it consumes, subscribing to the ones it provides, and answering its calls with the right contents in time. On a rig, the simulator takes on those roles. The services, methods, events and data types come from the AUTOSAR ARXML system description, so the simulated ECUs offer exactly what the real ones would.
We integrate SOME/IP into real-time rigs over automotive Ethernet, with fault injection such as offers that stop, subscriptions that are never acknowledged and responses that carry error codes, so you can see how the ECU under test copes. If you are building a rig with service-oriented ECUs, get in touch.
Sources
- AUTOSAR, SOME/IP Protocol Specification, Foundation R24-11, document 696
- AUTOSAR, SOME/IP Service Discovery Protocol Specification, Foundation R24-11, document 802