QORIX SOME/IP gateway PoC

[pawelrutkaq]

No description provided.

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.3.0) and connecting to it...
INFO: Invocation ID: ccfbe1f6-4002-46a3-a0e8-3193c1eb7354
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-eQOopREOYCL5vtTb6c1cwZrql4GVrJ1FqgxarQRe1xs="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:394:31: in <toplevel>
WARNING: For repository 'aspect_rules_lint', the root module requires module version aspect_rules_lint@1.0.3, but got aspect_rules_lint@1.5.3 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'buildifier_prebuilt', the root module requires module version buildifier_prebuilt@7.3.1, but got buildifier_prebuilt@8.2.0.2 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'googletest', the root module requires module version googletest@1.14.0, but got googletest@1.14.0.bcr.1 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
WARNING: Target pattern parsing failed.
ERROR: Skipping '//:license-check': no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/inc_someip_gateway/inc_someip_gateway/BUILD
ERROR: no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/inc_someip_gateway/inc_someip_gateway/BUILD
INFO: Elapsed time: 11.613s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

[github-actions]

The created documentation from the pull request is available at: docu-html

[lurtz]

I am not feeling well with pushing this through.

First everything is in Rust. As we have no safety qualified Rust toolchain, I prefer code which has to meet ASIL-B requirements to be in C++. I know that is absurd, but in the worst case we have to rewrite the Rust in C++. At S-CORE architects Rust is also a topic with a heated discussion: https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14891648
S-CORE decided to write new code in Rust, but they do not know if that can be safety qualified until the release.

Next is the use of Iceoryx2. I thought we only use one IPC mechanism in S-CORE.

[qor-lb]

@lurtz the final decision on using Rust for safety-critical components is planned for February, which is roughly 2 months from now (accounting for christmas vacation and new years eve). From my point of view, the period until then can still be treated as PoC and architectural exploration rather than series delivery. Based on that, I propose to continue the gateway PoC in Rust for now.

Reasoning:

1. Rust requires explicit handling of ownership, lifetimes, mutability and concurrency. This forces us to clarify data flow and resource responsibilities at design time rather than after code has grown.
2. In C++ it is possible to move faster at the beginning but with a higher risk of implicit coupling and unclear lifetime rules that only surface under load, fault injection or late integration. This is not a critique of C++ as a language, but of the freedom it gives without structural guardrails.
3. At this stage architectural clarity provides more value than early completeness or language aligned code.
4. If the February decision leads to C++, we still gain from a design that has already accounted for ownership logic and concurrency correctness. The design documents, data flow diagrams and interface contracts stay valid.
5. Side note: At the moment we do not yet have established tooling inside S-CORE to enforce rulesets like MISRA for C++ for a safe language subset. This does not block C++ as an option, but it means that C++ does not currently give us immediate compliance assurance either.

This treats Rust as a tool for architectural stress testing, not as a language commitment. If there are concrete downsides to this approach, let us list them so we can evaluate them openly.

[pawelrutkaq]

I am not feeling well with pushing this through.

First everything is in Rust. As we have no safety qualified Rust toolchain, I prefer code which has to meet ASIL-B requirements to be in C++. I know that is absurd, but in the worst case we have to rewrite the Rust in C++. At S-CORE architects Rust is also a topic with a heated discussion: https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14891648 S-CORE decided to write new code in Rust, but they do not know if that can be safety qualified until the release.

Next is the use of Iceoryx2. I thought we only use one IPC mechanism in S-CORE.

'Iceoryx2' is used behind mw_com interface, so it does not matter in S-CORE as there is no new API binding for Lola. The channel to SOME/IP stack is going to change anyway as we discussed.

[LittleHuba]

Hey all,
this PR is currently not aligned in the communication CFT. This must be reevaluated, with the new information that Rust is not mandatory for new implementations anymore.

Please don't get me wrong, I find Rust cool and want to have it in S-CORE. And to do that we have to do one step after the other. One crucial first step is to achieve qualification readiness for Rust. And in the last meeting it was agreed that the timeline is at least difficult to meet.
With this understanding, introducing more and more Rust code into the project at this stage comes with a risk. The risk that we have to exclude all these parts from the release. I hope that I'm correct in evaluating releasability higher than introducing more Rust code in our project.

We agreed in the last Communication FT weekly that we postpone the ASIL-B part of the gateway as far as we can, in the hope of having a better understanding of the qualification timeline of Rust.

So please everybody, adhere to what we agreed in the weekly. I understand, that the discussion was cut short yesterday, because we ran out of time. Let's discuss this in the breakout session for the gateway further.

[LittleHuba]

'Iceoryx2' is used behind mw_com interface, so it does not matter in S-CORE as there is no new API binding for Lola. The channel to SOME/IP stack is going to change anyway as we discussed.

@pawelrutkaq I strongly disagree. Consensus in S-CORE is that there is no code duplication. Introducing a second IPC framework is violating this decision. Further, including iceoryx here completely ignores the concerns the project raised in terms of code qualification.

As we agreed, for a MVP it was okay that you did this shortcut. But for inclusion in the S-CORE project we require the switch to mw::com with LoLa underneath.

Please let's finish the discussion for our approach to the gateway before we go ahead.

[mikehaller]

As #2 has been merged, can we close this PR?