Onboarding Autosar

[AlexanderLanin]

Onboarding Autosar

S-CORE – Overview

Repeated here for completeness

• 📚 Process Model & Introduction
• 📌 Workproducts & Traceability
• 🧪 SW Development, SW Verification, Safety Plans
• 🧩 Process Areas:
  • Requirements Template
  • Detailed Design Example
  • Architecture Example
  • Linking to Source
• 🗺️ Roadmap

Use Case

AUTOSAR wants to develop an automotive grade reference implementation. S-CORE has the necessary processes and tools which AUTOSAR can use for their development. Using the same approach will allow for an easier integration of S-CORE with AUTOSAR. This discussion focuses on tooling & integration.

Constraints:

• AUTOSAR will be using a different licensing. Some source available license like CC-NC. Therefore we cannot integrate any code into eclipse-score.
• AUTOSAR is using different tooling and infrastructure at the moment (details below)

Conceptual Overview

General idea:

Including compatibility layer:

---

Level Mapping

Not even a draft, this is just to indicate the idea of what we need to map

S-CORE	AUTOSAR
?	feature
feature	functional component
component	component?

Rough mapping to a V-Model (workshop output 2025-13-27):

Yet another integration idea (NEW 2025-04-16):

editable source: https://excalidraw.com/#json=107LJGYaVBpcrWfUegwTb,q-Ga-CLLQwBhlifvJUwCAQ

---

Tooling Comparison

Area	S-CORE	AUTOSAR	Alignment
Repositories	GitHub eclipse-score	GitLab	❌ Alignment unlikely? Or can we motivate Autosar to implement in GitHub?
Automation	GitHub Actions	Jenkins	❌ Alignment unlikely, see above
Requirements/spec	Sphinx-needs	Latex?	❓Alignment/conversion possible?!
Architecture	Sphinx-needs, PlantUML, Draw.IO	EA	❌ Alignment unlikely❓Export from EA
C++	C++17	C++14	✅ Alignment likely
C++: formatting	clang-format	clang-format	✅ Alignment likely
C++: unit testing	gtest	gtest	✅ Alignment likely
C++: build system	bazel	cmake	❓Should not be a major problem, as we can trigger CMake from bazel? bazel-bazel would be easier though
C++: Detailed Design / Documentation	Doxygen?	Doxygen for code documentation, with lots of keywords like @param, @returns, @throws, @see, @note etc	✅ Alignment likely
C++: dependencies	gtest+ google_benchmark	gtest + ?	✅ Alignment likely
C++: code analysis	gcc, clang, clang-tidy, ?	cppcheck + propriatary	✅ Alignment likely (80%)
C++: coding rules + style	MISRA + Google/Core	MISRA + Custom	✅ Alignment likely
C++: file naming rules	-	-	✅ Alignment likely
How to run tests on QNX	❓	docker	✅ Alignment likely??
??	-	yocto for ??	??
Supported development environment	not sure	Ubuntu 16.04	❓Alignment possible?!
Copyright header (=License)	Apache 2.0	?	❌ Alignment impossible
Linking code to requirements	Via req-Id	Via @uptrace{req, hash} and testtrace	✅ Alignment likely
Python	3.13	3.4	❓Alignment possible?!
Python coding rules	custom	custom	✅ Alignment likely
Python code analysis	ruff, pyright	pycodestyle	✅ Alignment likely
git workflows	short lived feature branches	short lived feature branches	✅ Alignment likely
review guidelines & checklists	custom	custom	❓Alignment possible?!

[AlexanderLanin]

A short report from the AUTOSAR workshop

My personal summary – perhaps others, specifically @aschemmel-tech, have additions or corrections.

---

TL;DR:
The meeting was productive. We received a few work packages. We might have some gaps in S-CORE and we failed to show a Code-First approach.

---

Meeting

On the S-CORE side, we presented an integration approach (images above) as well as the S-CORE processes (links above).
In general, there was a perceived acceptance of reusing things for the AUTOSAR reference implementation –
of course with some caution as to whether the processes, infrastructure, and especially tools really fit.
There was also a discussion about keeping only the artifacts compatible. I believe that would be a lose-lose.

---

Work Packages

There are three concrete work packages coming up for dedicated groups from S-CORE and AUTOSAR.
Without S-CORE’s own investment, this won’t come together – at least not in the S-CORE sense.

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.
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 in S-CORE

• 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).

---

Official AUTOSAR meeting minutes will be pusblished here as well, upon legal clarification.

[AlexanderLanin]

Follow-Up Discussions

• Tooling Comparison with AUTOSAR
• AUTOSAR / S-CORE artifact mapping
• Mapping requirements levels to AUTOSAR