Feature Request for DDS Gateway#2997
Conversation
github-project-automation
Bot
added this to
TLC - Technical Lead Circle and S-CORE Roadmap
|
The created documentation from the pull request is available at: docu-html |
qor-lb
added
community:architecture
feature_request
ft:communication
LittleHuba
left a comment
LittleHuba
left a comment
There was a problem hiding this comment.
Blocking this PR formally until agreement is achieved in Communication FT.
There was a problem hiding this comment.
I would like to place the same requests as we agreed on with the SOME/IP gateway.
- How a translation from intra-ecu to inter-ecu communication is integrated in the system is very much up to the integrator.
- The DDS gateway implementation that S-CORE provides is only a showcase on how this problem can be solved. Users must be able to implement/integrate a different DDS translation concept (e.g. one without explicit gateway process).
- The DDS logic must be a binding beneath mw::com (e.g. the gateway internally uses mw::com to interact with the DDS stack) This is the foundation of supporting different integration concepts.
| - End-to-End (E2E) protection: | ||
|
|
||
| - Centralized handling of Counter, CRC, and DataID | ||
| - Validation and protection configurable per route |
There was a problem hiding this comment.
E2E protection handling might be impossible to achieve in a centralized handling. In some of our supported operating systems the network stack is not qualified.
The SOME/IP gateway works around this with a split of the "gateway process" into a QM and an ASIL-B part.
|
|
||
| - Configurable routing: | ||
|
|
||
| - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics |
There was a problem hiding this comment.
I'd be interested in more detail on this mapping.
What are the supported mapping cases? What are the corner cases where support is not provided?
It is hard to judge feasibility without further details.
| - Configurable routing: | ||
|
|
||
| - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics | ||
| - Support for DDS domain-based routing |
There was a problem hiding this comment.
Same here, please add more details / link to references.
I'm not a DDS expert so I need some more background to judge.
|
|
||
| - Dynamic Type handling: | ||
|
|
||
| - Runtime type definition via configuration or via dynamic library |
There was a problem hiding this comment.
This sounds like we have a huge overlap with the SOME/IP efforts. The format might differ, but the general task is the same. I'd like to see an investigation on how much we can reuse from the upcoming SOME/IP infrastructure.
|
|
||
| - DDS stack abstraction: | ||
|
|
||
| - Pluggable DDS implementations via defined interfaces |
There was a problem hiding this comment.
Ideally this stack abstraction is mw::com (as highlighted in a previous comment)
3 participants
DDS Gateway: Recreated PR following accidental merge/closure of the previous PR. No functional changes beyond the requested modifications.