SOME/IP Specification Cleanup #117

stevenhartley · 2024-04-18T00:50:59Z

The following change is a reboot of the SOME/IP specifications in an attempt to drastically simplify to show how we map up-l1 messages to SOME/IP messages and uSubscription messages to SOME/IP-SD messages. the older specifications had a lot of uProtocol version 1.3.6 concepts (cloudevents) that were rather complicating the situation.

#93

The following change is a reboot of the SOME/IP specifications in an attempt to drastically simplify to show how we map up-l1 messages to SOME/IP messages and uSubscription messages to SOME/IP-SD messages. the older specifications had a lot of uProtocol version 1.3.6 concepts (cloudevents) that were rather complicating the situation. #93

int0x27 · 2024-04-18T08:25:20Z

up-l1/someip.adoc

+
+Scalable service-Oriented MiddlewarE over IP (SOME/IP) is a communication protocol used in the automotive industry for exchanging data between electronic control units (ECUs) in a vehicle. 
+SOME/IP provides a framework for efficient and reliable communication between ECUs over IP networks. It is designed to support real-time and high-bandwidth communication requirements in automotive systems. The protocol allows ECUs to discover and communicate with each other, exchange messages, and provide services in a distributed system.
+SOME/IP is based on the Internet Protocol (IP) and uses UDP (User Datagram Protocol) as the transport layer. It supports various communication patterns, including unicast, multicast, and broadcast. The protocol defines a set of message formats and procedures for encoding and decoding data, handling service discovery, and managing communication sessions.


SOME/IP also uses TCP transport

int0x27 · 2024-04-18T08:52:48Z

up-l1/someip.adoc

+
+|*`UEntity::id`* |Service ID |Software entity ID that is placed in the upper 16
+bits of the SOME/IP Message ID header field
+


SOME/IP header does not include Instance ID, but it is used in SOME/IP SD and also required for vsomeip/sommr API.
Can we map it to UUri? e.g. ServiceID | InstanceID both u16 as UAuthority::id: u32

UUri spec also refers to UResource instance, but maybe it is outdated.

As I checked again UUri spec, we don't have u32 id to use for ServiceID + InstanceID.
It could be handled as a client option per Service ID along with major/minor service version.

per discussion below, we will stick with instance 1. Need to discuss instance id further though.

int0x27 · 2024-04-18T08:53:25Z

up-l1/someip.adoc

+bits of the SOME/IP Message ID header field
+
+|*`UResource::id`* |Method/Event ID |Identifier of the method/resource placed in the
+lower 15 bits of the SOME/IP Message ID header field


int0x27 · 2024-04-18T09:27:23Z

up-l1/someip.adoc

+
+link:../basics/uuid.adoc[uProtocol UUID specifications] create a unique identifier for each message along with timestamp information. the ID is used for correlate between request and response as well. SOME/IP instead defines the ID as 16bit client ID + 16 bit session ID (that is incremented). When messages are converted SOME/IP to/from uProtocol, care must be taken to ensure that the SOME/IP ID and uProtocol UUID are properly mapped, especially when corelating a request to a response. 
+
+* Generated SOME/IP events *SHOULD* set the 16 bit client ID to 0 per SOME/IP specifications 4.1.2.4


Maybe you should refer to [PRS_SOMEIP_00925]?

• Set the Client ID to 0x00. Set the Session ID according to
[PRS_SOMEIP_00932], [PRS_SOMEIP_00933], and [PRS_SOMEIP_00521].
In case of active Session Handling the Session ID shall be incremented upon
each transmission.

int0x27 · 2024-04-18T09:31:01Z

up-l1/someip.adoc

+|`UMESSAGE_TYPE_PUBLISH` or `UMESSAGE_TYPE_NOTIFICATION` |`NOTIFICATION` |Both publication and notifications events are the same for SOME/IP
+
+| `UMESSAGE_TYPE_REQUEST` |`REQUEST` |Requests type message
+


Shall we handle REQUEST_NO_RETURN as per [PRS_SOMEIP_00055] for fire and forget requests?
Could be handled internally for the client

int0x27 · 2024-04-18T09:54:11Z

up-l1/someip.adoc

+|`NOT_FOUND` |`E_UNKNOWN_SERVICE`
+|`UNAVAILABLE` |`E_NOT_READY`
+|`DATA_LOSS` |`E_MALFORMED_MESSAGE`
+|`INTERNAL` |`E_NOT_REACHABLE`


Also add: E_NOT_OK here

E_WRONG_PROTOCOL_VERSION, E_WRONG_INTERFACE_VERSION not described as well

For more error codes add link to SOME/IP Protocol specification: [PRS_SOMEIP_00191]

done, @int0x27 please check

int0x27 · 2024-04-18T10:01:44Z

up-l1/someip.adoc

+
+The following section will elaborate only on the translation of uSubscription messages to/from SOME/IP-SD messages. Subscription state (persistent or not) is handled in the uSubscription services and not at the transport layer or this component.
+
+The following section we will elaborate on how Eventgroup Entry types (5.1.3.1) are mapped to uSubscription messages for the subscribe


As it was harder to find this reference, can you also mention [PRS_SOMEIPSD_00385]

int0x27 · 2024-04-18T10:38:02Z

up-l1/someip.adoc

+|===
+|Eventgroup Entry Field |UUri
+
+|Service ID |`UEntity.id`


NOTE: For API calls also Instance ID is required, but could be defined as static configuration in the client.
Can we add it to UAuthority::id?

We are merging back name, ip, and id per #120 so it is no longer ambiguous (and split into three parts). This means that the name has to be either ip address, a hostname, or an id and has to be globally unique.

int0x27 · 2024-04-18T10:42:04Z

up-l1/someip.adoc

+
+|===
+
+NOTE: `UUri.authority.ip` is translated to/from IPv4 (and/or IPv6) Endpoint Option of the SOME/IP-SD message


vsomeip API does not provide anything to get remote endpoint IP, it uses <service/instance/..> mappings internally to find which tcp/udp endpoint is used.
For me setting remote IPs in the authority for SOME/IP seems wrong.

@int0x27 the idea is discovery has the location of the service/instance and can translate that to the endpoint (ip address) that is used to build uAuthority. So we cannot have the same service +instance hosted on different devices (ip address)? I think this is the endless loop of why we have instance id :-(

int0x27 · 2024-04-18T10:45:46Z

up-l1/someip.adoc

+|`SubscriptionRequest` 
+a|The message is used to subscribe to a topic.
+
+* Instance ID *SHALL* assume to be 0


Instance ID should be arbitrary value expected from the SOME/IP service. e.g. if you hardcode 0 and the service only handles instance 1, subscription will be NACKed.

Per discussion thread I'm changing this to 1 in lieu of 0

int0x27 · 2024-04-18T10:56:43Z

up-l1/someip.adoc

+
+* Instance ID *SHALL* assume to be 0
+* *SHALL* assume version 0 to match uProtocol backwards compatibility requirements
+* TTL (`SubscribeAttributes.ttl`) *SHALL* set to 0xFFFFFF to indicate that the subscription should remain for the duration of the ignition cycle


Remark about vsomeip: there is global Service Discovery TTL (static config) and it is used for all subscriptions. It's not possible to have it per service or dynamic. Probably it should match remote service shortest TTL

@int0x27 , given your comment, should we assume live forever?

int0x27 · 2024-04-18T11:01:13Z

up-l1/someip.adoc

+a|The message is used to subscribe to a topic.
+
+* Instance ID *SHALL* assume to be 0
+* *SHALL* assume version 0 to match uProtocol backwards compatibility requirements


do you mean Major Version here? The service may NACK the subscription if it requests different major version.

No the UService.id but the text is not clear, I cleaned it up a bit

int0x27 · 2024-04-18T11:09:24Z

up-l1/someip.adoc

+response.reqid = request.id
+```
+
+* Auto-generated SOME/IP REQUEST message, *MAY* set the 16 bit client ID to the 0 per SOME/IP specifications 


This is only for notifications, but not requests

@int0x27 do we need to explicitly state this?

ruchirchauhan · 2024-04-18T13:23:21Z

up-l1/someip.adoc

+
+|Major Version | `UEntity.major_version`
+
+|Eventgroup ID | `UResource.id`


Since Eventgroup ID and Event ID both are being mapped to UResource.id, I am guessing it means that this still doesn't support multiple event ids in an eventgroup and that eventgroup id should be equal to event id ?

Even if we have 1 : 1 mapping for events and groups, they should be different IDs for the client library.
Everything is hardcoded in the SOME/IP service and the client library must follow those defined IDs.

I suggest we use Event ID as the primary mapping (as UResource.id) also for subscribe().
The client implementation may look up its static configuration to get additional information about Eventgroup ID to call subcribe(), but then events will be coming with Event ID, so subscribing to that Event ID makes more sense.

As a side effect subscribing to ECU with multiple events in the event group may trigger receive on_message() notifications for other events as well (those can be filtered on client level)

I liked Ivan's suggestion. lets keep event group logical entity (i.e. not defined in uProtocol). we can map an event group or event groups to a service. also we can consider adding new api in sdk for registerListnergroup() which can be used for registering logical events (event id) for a services/event group.

fixed in latest change.

stevenhartley · 2024-05-28T19:42:15Z

Closing so we can use #165 instead

int0x27 reviewed Apr 18, 2024

View reviewed changes

ruchirchauhan reviewed Apr 18, 2024

View reviewed changes

Addressed a lot of reviewers comments

aa92210

stevenhartley requested review from int0x27, sagarsshah and ruchirchauhan April 22, 2024 20:19

stevenhartley added the v1.5.8 label May 16, 2024

stevenhartley closed this May 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SOME/IP Specification Cleanup #117

SOME/IP Specification Cleanup #117

stevenhartley commented Apr 18, 2024

int0x27 Apr 18, 2024

int0x27 Apr 18, 2024 •

edited

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

int0x27 Apr 18, 2024 •

edited

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024 •

edited

int0x27 Apr 18, 2024

stevenhartley Apr 22, 2024

ruchirchauhan Apr 18, 2024

int0x27 Apr 18, 2024

sagarsshah Apr 22, 2024

stevenhartley Apr 22, 2024

stevenhartley commented May 28, 2024


		\|`UEntity::id` \|Service ID \|Software entity ID that is placed in the upper 16
		bits of the SOME/IP Message ID header field


		link:../basics/uuid.adoc[uProtocol UUID specifications] create a unique identifier for each message along with timestamp information. the ID is used for correlate between request and response as well. SOME/IP instead defines the ID as 16bit client ID + 16 bit session ID (that is incremented). When messages are converted SOME/IP to/from uProtocol, care must be taken to ensure that the SOME/IP ID and uProtocol UUID are properly mapped, especially when corelating a request to a response.

		* Generated SOME/IP events SHOULD set the 16 bit client ID to 0 per SOME/IP specifications 4.1.2.4

		\|`UMESSAGE_TYPE_PUBLISH` or `UMESSAGE_TYPE_NOTIFICATION` \|`NOTIFICATION` \|Both publication and notifications events are the same for SOME/IP

		\| `UMESSAGE_TYPE_REQUEST` \|`REQUEST` \|Requests type message


		The following section will elaborate only on the translation of uSubscription messages to/from SOME/IP-SD messages. Subscription state (persistent or not) is handled in the uSubscription services and not at the transport layer or this component.

		The following section we will elaborate on how Eventgroup Entry types (5.1.3.1) are mapped to uSubscription messages for the subscribe


		\|===

		NOTE: `UUri.authority.ip` is translated to/from IPv4 (and/or IPv6) Endpoint Option of the SOME/IP-SD message


		\|Major Version \| `UEntity.major_version`

		\|Eventgroup ID \| `UResource.id`

SOME/IP Specification Cleanup #117

SOME/IP Specification Cleanup #117

Conversation

stevenhartley commented Apr 18, 2024

Choose a reason for hiding this comment

int0x27 Apr 18, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

int0x27 Apr 18, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevenhartley Apr 22, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevenhartley commented May 28, 2024

int0x27 Apr 18, 2024 •

edited

int0x27 Apr 18, 2024 •

edited

stevenhartley Apr 22, 2024 •

edited