Follow-Up AUTOSAR process & tooling meeting

[AlexanderLanin]

Based on #759 we need to create tasks.
Let's do that here - until we come up with some better structure.

Task by Project Leads Circle: estimate effort and quantify effect on 0.5 milestone

Tasks --> Process:

1. The various requirements and architecture levels need to be aligned (see level mapping above)
2. The next step is to align the complete list of artifacts to be generated.

Tasks --> Infrastructure:

3. In parallel to the above, we can align infrastructure and tooling (see tooling comparison above) In an extreme case, the AUTOSAR reference implementation could use the S-CORE module template (win-win).

Gaps --> Process:

• A frequently mentioned difference between S-CORE and AUTOSAR is that S-CORE follows a code-first approach.
  Unfortunately this didn’t come across at all during our presentation.
  Especially writing interfaces in Sphinx-Needs seems like a disastrous contradiction.
• A major topic in AUTOSAR is conflict resolution, for which we couldn’t present an equivalent in S-CORE (maybe missing, maybe a gap in the knowledge of participants).
• Related to that, the question arises: where in S-CORE are implementation-independent interfaces represented?
• An approach for different modules which fulfill the same feature, with slightly different capabilities. Example: persistency which can write to filesystem (or some other system).

@aschemmel-tech do you have any more tasks?
Yes:

• Figure out how S-CORE deals with the non-availability of AUTOSAR interfaces definition. Who will provide the "adapter" or "compatibility" layer? What are legal constraints, e.g. how different the S-CORE interfaces must be to avoid copyright problems?

---

Infrastructure effect: We need 4 person days to make a 80% match, so we have a list of the concrete difficult cases. Those we exclude for now! -> milestone 0.5 delayed by 1 day.

Process effect:

• req/arch level alignment: 1 full day workshop, two persons, assuming we will not need to rework our process
• artefacts alignment: about 50 artefacts * 0.5h each, assuming we will not need to rework our process
• gaps: code-first: should be rather called "code-centric". Our process expects feedback from implementation and testing on requirements (see flow in https://eclipse-score.github.io/score/main/process/general_concepts/score_review_concept.html#inspection-conduct) and also covers the use of pre-developed OSS (see https://eclipse-score.github.io/score/main/process/process_areas/safety_management/guidance/template_component_classification.html) - so this is covered in a ISO 26262 compliant way already.
• gaps: conflict resolution: we do not see the need of an additional level of architecture/documentation above the S-CORE features, as "conflict resolution" is covered by the feature architecture already: if more than one feature uses one component the conflict has to be managed during feature architecture definition and adapting component requirements if needed. Expectations from components towards its users are managed be Assumptions-Of-Use.
• gaps: interface definition: this is a topic we need to discuss between process and architects communities. Currently we see a discrepancy in the need for "implementation independent interfaces" - which would be the feature level "logical interfaces" and on the other hand we want to work code centric. This is hard to estimate, but maybe we need to resolve this anyway regardless of AUTOSAR alignment. I would say it is 40h for finding a solution and another 40h for implementing it in our process.
• overall I think this would sum up to two weeks delay because the tasks are not easy to split up and probably affecting ressources on the critical path.
• non-availabilty of AUTOSAR interfaces: I think it is a tech-lead or project lead topic, with impossible to estimate effect.

[AlexanderLanin]

Some more details on the interfaces:

• AUTOSAR and S-CORE define (logical) interfaces & operations in non-code format. Which, to my understanding, AUTOSAR has learned is a bad idea. Too much overhead, too many problems with non-implementable interfaces, too many interfaces which sound good on paper, but are extremely unpractical when implemented. Our approach with docstrings in code sounds ideal - but it's only used for "real" interfaces & operations.
• Where does SCORE store the real interfaces as implementation independent code, so modules/components can depend on other modules/components without depending on a concrete implementations? Also that's the only way to make modules/components exchangeable.

[AlexanderLanin]

AUTOSAR/S-CORE requirements level mapping -> @aschemmel-tech
AUTOSAR/S-CORE tool infrastructure -> @AlexanderLanin
AUTOSAR/S-CORE artifact mapping -> @aschemmel-tech probably..., @AlexanderLanin will join as well

[AlexanderLanin]

@aschemmel-tech sorry, it seems I documented the "code centric" approach incorrectly here. The point was not about compliance, but about too much overhead. Let's have a call on it.

[AlexanderLanin]

@aschemmel-tech should we split this to ~8 separate issues? It will be a mess here otherwise...