SOME/IP specification cleanup

[int0x27]

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.

(based on PR-117, that can't be merged at the moment)

Fixes #93

[stevenhartley]

I think we need to elaborate more on this portion. The URI can be either a host or IP address. If the authority_name is host, we need to then resolve to an IP address in the transport implementation.

[PLeVasseur]

Curious to learn more here too.

[int0x27]

vsomeip gets the required endpoint information (via service discovery or static json configuration), but they have decided to leave it private for the implementation, so you have a better abstraction of SOME/IP services/instances/methods available in the network.

e.g. it is possible to have multiple endpoints (hosts) offering the same service, but with different instance or version. vsomeip router aggregates all discovered service/instance information and maps the endpoint to service/instance/major_ver/minor_ver/[method | eventgrup/event]
API requires service and instance as minimum.

The only way I see to provide the mDevice IP:port in authority_name is to have it pre-configured (mapped to service/instance pair).

If "host" means any string, it could be created from service/instance pair, e.g. <service>.<instance>v<version>, but then that same information is present also in ue_id, ue_version_major

[stevenhartley]

I think you need to elaborate more what is meant here. A service (and instance) is deployed to a given ECU device that has an IP address, I don't think it is hidden per say.

[int0x27]

Although it's not hidden by the protocol, it is hidden by the implementation. You can't work directly with the endpoints, so they have abstracted them by service/instance/..

[stevenhartley]

Per our chat, this is a different type of message that is a request with no response correct?

[int0x27]

UMESSAGE_TYPE_NOTIFICATION was previously mapped to REQUEST_NO_RESPONSE, which seems wrong.

I can't tell whether to use UMESSAGE_TYPE_PUBLISH or UMESSAGE_TYPE_NOTIFICATION for incoming SOME/IP events. e.g. if we have a subscriber to the specific service/instance/event, it should be a UMESSAGE_TYPE_NOTIFICATION, if no subscribers are found send it as UMESSAGE_TYPE_PUBLISH?

[stevenhartley]

@int0x27 I don't understand this requirement, can you please explain what you mean here?

[int0x27]

I mean let the library do the Request ID manipulation.

The transport just needs to send() the request and cache the updated Request ID (as there are multiple cases, whether to increment Session ID or not).
Sending notifications also has automatic Request ID assignment.

// removed some lines about setting Client ID to 0 on events / incrementing the Session ID, etc.

[stevenhartley]

This is where we need to chat, I'm not sure how that would work. How do we know that service_id+instance_id maps to a specific IP address and port, is that static configuration that would be loaded into the uTransport implementation library?

[PLeVasseur]

Also very curious about this point.

I don't know vsomeip all that well, but from what I could see it seems to rely on static configuration of IP addresses and I couldn't figure out reading the vsomeip header how header contents tied back to an IP address.

If the answer is as you wrote and there is no IP address or logical name contained within the vsomeip header, how do we come up with this?

Must we then read that same vsomeip configuration to be able to correlate service and instance IDs with the IP address?

[int0x27]

Some other SOME/IP implementations, require you to specify all the local and remote endpoints in their static configuration along with their service/instance/methods, etc.

For vsomeip it can be also static (if service discovery is disabled) or auto-populated from service discovery.
Consider you want to use {service:0x1234, instance:2, method:0x0042, major_ver:1}

• The app registers on_available(service, instance, is_available) callback, possibly with ANY_SERVICE, ANY_INSTANCE artguments.
• App calls app->request_service(0x1234, ANY_INSTANCE, 1, ANY_MINOR)
• This generates Find Service Entry SOME/IP message [PRS_SOMEIPSD_00350]
  and all mDevice endpoints must return their 0x1234 service endponits (e.g. hostA provides instance 1, hostB provides instance 2)
• App receives on_available(0x1234, 1, true) and on_available(0x1234, 2, true) and then it can communicate with the choosen instance
• e.g. send a message to configured instance 2:

std::shared_ptr<vsomeip::message> rq = vsomeip::runtime::get()->create_request(use_tcp_);
rq->set_service(0x1234);
rq->set_instance(2);
rq->set_method(0x0042);
rq->set_interface_version(1); // major_ver
std::shared_ptr<vsomeip::payload> pl = vsomeip::runtime::get()->create_payload();
// serialize payload for method_id
rq->set_payload(pl);
app_->send(rq);

• vsomeip finds the discovered service/instance(2) and sends the request to HostB endpoint (app does not care about which host is providing it)
• You can also set rq->set_instance(1) and it will be sent to the other hostA

[stevenhartley]

This is changing in #163, it might be better to just state that ,the error codes below will be returned and not through SubscriptionStatus.code (it will be in commstatus of UAttributes)

[PLeVasseur]

Hi @int0x27 -- I don't know much about vsomeip yet.

I'm still a bit unclear on how the source and sink UUris map in.

Could I ask for some elaboration on how you see the source and sink UUris lining up with the SOME/IP header?

I'm looking for something akin to what was done for Zenoh or MQTT5.

I'd essentially like the kind of clarity laid out in those documents on how to map from the uP-L1 registerListener API down into the vsomeip header.

This kind of information will be essential when a uStreamer is fleshed out, as we'll need to be able to say things like:

"Give me all point-to-point (Request, Response, Notification) messages with a source authority of X, so that I can route them to sink authority Y"

and

"Give me Publish messages from topics A, B, and C, since I will need to bring those onto this host for dissemination to uEntities Foo: {A, B} and Bar: {C}"

[pranavishere2]

As per my understanding,
Service ID MUST be encoded in the lower 16 bits of ue_id and not 'resource_id'.
Please confirm

[pranavishere2]

As per my understanding,
uProtocol resource_id is mapped to method_id in someip header for RPC usecase and
uProtocol resource_id is mapped to event ID in someip header for Pub Sub usecase

Question: How are we going to map event group id in vsomeip ? If we assign event_id same as event_groupID then we may have a problem. We faced this issue few weeks ago where there was a use-case of different event_id and event_group ID

FYI In someip world,
At client side,
Event ID and event group ID both needs to be provided while calling request_event API and "event groupID" needs to be provided again for subscribe API.

At server side,
same event ID and event group ID needs to be provided while calling offer_event API

[int0x27]

My opinion is still in favor of using Event ID for both PUBLISH and SubscriptionRequest.topic.resource_id.
This needs additional configuration for the transport (mapping Service/Instance/Event to a set of eventgroup IDs), but it allows a lot more flexibility in supporting ECUs.
The other option: forcing ECUs to have EventID=EventGroupID is a lot more restrictive for the HW and not OSS friendly. This can be assumed as "default" option - if no mapping is provided per event, assume EventID=EventGroupID

[pranavishere2]

As per my understanding,
uProtocol "ue_version_major" is mapped to Service Major Version in someip. What about minor version?
In someip world, minor version is also required at the time of offer service at server side and request service at client side. We will have a problem when mE would try to offer a service with different minor version and Streamer(up-client-vsomeip-cpp) will need to request the same service with that specific minor version.
I think, we need a mapping of ue_version_minor to map it to vsomeip Service Minor version as well.
OR
Are we suppose to use ANY_MINOR as a default while invoking "request_service" vsomeip API call and that way no mapping is needed?
Please confirm

[int0x27]

minor version is needed indeed , if omitted vsomeip assumes vsomeip::DEFAULT_VERSION=0x00000000.
The same applies for major version (assumed 0x00, if not provided)
As minor is not available in uProtocol, I suppose it should be a transport configuration (especially for offered services).
For requested services we can get away with vsomeip::ANY_MINOR

The transport MUST know in advance which services/instances/major/minor and events it MAY interact with and pre-register them in the vsomeip router. It could be possible to request the event in e.g. on_available handler, but that may block the dispatcher thread for too long and you'll get vsomeip warnings.

[stevenhartley]

please see feedback comments

[stevenhartley]

@int0x27 I think we are OK to merge, next week we can add specific mappings of the uTransport API given the work that Peter has done on up-transport-vsomeip-rust.

[int0x27]

OK, just rebased on main, squashed some commits

[stevenhartley]

LGTM for now, we'll add to it more for uTransport specifics next week