Draft someip-network-daemon architecture #2342
Conversation
crimson11
force-pushed
the
mf_vsomeip_daemon_arch
branch
3 times, most recently
from
365aafa to
0f49d88
Compare
crimson11
force-pushed
the
mf_vsomeip_daemon_arch
branch
from
0f49d88 to
aaf635c
Compare
There was a problem hiding this comment.
Typo: It should be "Daemon" not "Deamon"
| For resource reasons, there will be only one instance of `vsomeip_v3::application` running within the | ||
| `SOME/IP network daemon`. |
There was a problem hiding this comment.
In order to calculate the E2E checksum the Request ID [Client ID | Session ID] needs to be known at the ASIL side. Therefore it would make sense to calculate the Session ID at the ASIL side. That can only be done if each ASIL client gets a separate Client ID because otherwise two ASIL clients calling the same method via SOME/IP would cause a conflict. As far as I can grasp from the documentation of vsomeip_v3::application::get_client() this would imply that the network daemon has to create a separate application object for each ASIL client.
| 3. The `SOME/IP network daemon` receives the message in (2) and creates the proxy from the information contained. I.e. it | ||
| issues a `score::mw::com::GenericProxy::FindService` and expects to get instantly a handle back, from which it then | ||
| creates the proxy instance. | ||
| Afterward, it is capable of accessing the event/field slots: The DATA channel is now set up. |
There was a problem hiding this comment.
The network daemon should send a reply. For methods it needs to create a DATA skeleton used to communicate back responses and return that LoLa instance id to the upper layer. In general it might be useful for the upper layer to know when the setup is complete.
| 2. Then the upper layer sends a message via `score::message_passing` to the `SOME/IP network daemon`, to create the | ||
| SOME/IP service instance. Thus, the message contains a tag/message-id `CreateServiceInstance`. Further payload of this | ||
| message: | ||
| - `SomeIpServiceInstanceId` describing the service instance |
There was a problem hiding this comment.
Probably we need more config data (event ids, event groups, ports, etc.). How do we exchange that? Should each upper layer initially send a registration message which then spins up the application instance? The registration message could contain a flatbuffer with all of the config data and the reply could contain data like the Client ID assigned to the upper layer.
There was a problem hiding this comment.
What is the main message of this sequence diagram? It is a bit confusing to me. Is it maybe detailed design? Then we should remove it from here and move it to the module documentation.
|
|
||
| 1. The upper layer sends a message via `score::message_passing` to the `SOME/IP network daemon`, to trigger the search/ | ||
| discovery for the service instance on the SOME/IP (network) side. Thus, the message contains a tag/message-id | ||
| `DiscoverServiceInstance`. Further payload of this message: |
| `score::message_passing` to the `SOME/IP network daemon`, to push the update to the SOME/IP service instance. Thus, | ||
| the message contains a tag/message-id `UpdateEvent`. Further payload of this message: | ||
| - `SomeIpServiceInstanceId` describing the service instance. | ||
| - `EventId` describing which event/field to update |
There was a problem hiding this comment.
| - `EventId` describing which event/field to update | |
| - `ComponentId` describing which event/field/method to update |
In AUTOSAR SOME/IP the "Method ID" is used for all of the components. Methods have a Method ID in the range [0-0x7FFF] and events/fields have a Method ID in the range [0x8000-0xFFFF]. At least that is what is the nomenclature in the AUTOSAR specification. In the Open SOME/IP specification they introduced the Method ID and Event ID which is then the AUTOSAR Method ID without the highest bit. I mean it was confusing before, but now we have the same name used for different stuff in each specification.
Possible alternative terms: MemberId, ElementId
| But since a lot of the proxy side functionality is deeply coupled with service-discovery functionality, bypassing it | ||
| seems to generate a lot of effort! Thus, we will use existing `OfferService` (skeleton) and `FindService` (proxy) | ||
| functionality. |
There was a problem hiding this comment.
What would we need to simplify this? Can we make an issue to solve that?
2 participants
No description provided.