[Contribution Request] Deterministic App Abstraction Layer (DAAL)

[FScholPer]

This is the call for contribution for the modification request [Deterministic App Abstraction Layer].

If you plan to contribute an implementation please create a subticket to this epic.

Any contribution shall be made available in a branch of the daal incubation repository

Reference: #864

Acceptance criteria:

• All contributions are announced 1 week prior to the workshop (deadline: 26th October 2025)
• Contribution is made available as a PR to the incubation repo (deadline: 3rd November 2025), including a summary of the contribution with the following information:
  • High-level architecture of the implementation
  • Relation to the goals defined in the feature request
• Per contribution a 30 min pitch is held during the workshop (4th - 6th November 2025, MBTI Ulm)
• Consensus on contribution is reached by 5th December 2025 (fallback voting by TLs on 8th December 2025)

[qor-lb]

Potential pitches:

• MB TI (@timkl7, nov is feasible)

Candidate for november.

[chheis]

Preliminary Meeting Minutes

@timkl7 please upload the shown slides here
Preliminary Meeting Minutes:

"Feature Request for Deterministic App Abstraction Layer (DAAL) #864"
General presentation of Fault Management:

• Repo: https://github.com/eclipse-score/inc_daal
• Already running in series on the ADAS ECU within the MB CLA
• Uses the same defined interfaces like the "Code generation" presentation
• Q: How is the timing guaranteed?
• A: It depends on your integration scenario. Guarantees are given only for the underlying system.
• Q: Application Handler: Is this thread based?
• A: Yes this is supported. But it is only a small abstraction layer. So if it not supported by the underlying system.
• Q: Is there a overview of the layers? Where is the line between abstraction layer and the underlying system?
• Shown in code:
• Q: How is the mapping between the processes and the executors?
• A: Normally there is only on executor and on process.
• Checkpoints are used for e.g. Monitoring
  • Integrated with the Health Monitor (presented on Tuesday) already (in the example)
  • Replay can be easily used. Slide where the application can run in different environments
• Q: Is it on Build time or runtime?
• A: It is changed on build time. It depends on the build target.
• Q: Where is the graph configured?
• A: It is configured outside of the application.
• Q: Can this graph be configured independently?
• A: The execution graph is just depending on the trigger.
• A: You can also use the trigger as starting point, or use one executor triggering multiple applications.
• Example: If 5 applications needs to be executed. It is the decision by the integrator. (Implemented in Code)
• Statement: The integrator can choose how the execution
• You need a common understanding how you like to create your application flow.
• The DAAL Framework is giving you the flexibility to use all the flavors.
• DAAL is abstracting the lifecycle management easier.
• It is easier to test if it is implemented as pattern.
• Getting the Applications in a structured form of lifecycle.
• Q: How this is related to the existing concepts? FEO and Orchestrator
• A: It is overlapping with FEO. Multiple Application handler can be used.
• A: It is implemented for a current series platform.
• Q: Do we want to have more than more solutions? Or do we need to apadpt out current solutions to this aspects?
• A:
• Q: What do we do with the feature request presentation?
• A: It was already available in the first Architecture of S-Core.
• It is overlapping with FEO concepts.
• Q: What is the goal for DAAL contribution?
• A: It would be possible to use FEO and take over aspects into FEO.
• Statement: In Eclipse S-Core there is one execution stack. So the use case of adapting to other stacks.
• Q: Are there aspects what DAAL is needing in Eclipse S-Core for using DAAL.
• A: In the example it is already using S-Core parts.
• But the FEO integration is not yet looked at. But should be feasible.
• Building blocks like communication is directly useable.
• Statement: Is DAAL a application framework for a stack abstraction layer? What is on the layer of application level.
• Q (Nico): Can I map all my app framework features to DAAL?
• A (Nico): If yes, then the discussion is already solved.
• Q: We maybe need to adapt the vision/scope of S-Core about the application framework layer?
• The main question is if a OEM like to adapt the underlying stack to a new stack.
• The main issue was, that without a abstraction layer, the application configuration needs to be done for every stack again.
• Could be used e.g. for the SomeIP Gateway configuration.
• Adapative Autosar had been at this point already (this is why a lot of application framework is coming up)
• The discussion is about the vision of S-Core application framework
• Hint: It reminds to the prescribing the OS Layer abstraction.
• There is the same discussion in the "Code Generation" and "Communication"
• Statement: There is no C++ application framework already.
• Hypothesis: If there are applications frameworks accepted by S-Core, there must be a guarantee for continuing those.
• The Application Frameworks are solving a problem to exchange Middlewares. But this is not the main goal of S-Core. But they maybe are solving the same problems while supporting the Application developer to develop.
• Some aspects of the application framework needs to be fixed in the Eclipse S-Core scope
• If there is a core feature already implemented, the application framework is forbidden to reimplement those. (No Complex device drivers)
• If the Projects are merging in open source this would be beneficial for all.
• With the SomeIP Gateway it is already a application what is then the border between green and black?
• Q: The black box border is maybe to low (south bound)?
• Proposal: Open up a definition how applications frameworks are done
  Advice (Ian): Find a way that the application framework can compete together in open.
• Main goal for S-Core: We like to serve continuously having a working stack.
• Q: If DAAL is in, MB is maintaining is. If they stop, and nobody is taking it up, it dies. If there is no adoption it is out.
• If S-Core needs to be released in 2026 the mandatory goal is that the scope of S-Core is working together.
• Thilo: Let life them happily live together, there is maybe a converging point in future.
• Create a forum for all application frameworks to work and interact together.

Wrapping up:

• As S-CORE we need application frameworks to
  1. raise acceptance for users (to put something on the stack and actually use the stack) and
  2. for integration test work. DAAL would be one application framework that is capable of doing so.
• Application frameworks only use S-CORE stack features (northbound) and don't reintroduce S-CORE stack capabilities.
• This forms an exception to our statement, having only one implementation for a specific problem. This exception only applies to the Application Framework layer, not the other modules of the of the stack.

Next step:

• DR needs to be tackled: @qor-lb & @thilo-schmitt will prepare a DR to reflect the decision. S-CORE wants to support having multiple application frameworks in parallel to drive adaption in the user-space. The implications of this decision and the approach how now Application Frameworks are added to S-CORE will be detailed in the decision record.

Slides

20251106_DAAL_Pitch_Eclipse S-CORE.pdf

[anmittag]

@timkl7 your presentation is missing, can you add it please, thx

[FScholPer]

@timkl7 your presentation is missing, can you add it please, thx

added