Tooling Comparison with AUTOSAR

[AlexanderLanin]

Goal

In order to be (theoretically) compatible with AUTOSAR, it is sufficient to define a mapping between artifacts. However, that is kind of a loose-loose scenario: S-CORE has a lost of work to map them, and AUTOSAR needs to define their own process and tools.

Therefore we want to investigate just how much overlap we can achieve. If we use the same tools in S-CORE and AUTOSAR then any collaboration / integration is (theoretically) much easier => win-win!

e.g. AUTOSAR could use all our bazel abstraction, all S-CORE CI/CD abstractions, tool configs, etc etc.

Previous & parallel work

• Kick-Off
• AUTOSAR / S-CORE artifact mapping
• Mapping requirements levels to AUTOSAR

Alignment

Can AUTOSAR reference implementation use S-CORE Infrastructure, Tools, Tool-Configs? To be answered line by line.

Problem area

Area	S-CORE	AUTOSAR	Alignment
Repositories	GitHub eclipse-score	GitLab	AUTOSAR will clarify impact/costs of GitHub for the reference implementation 🟡
Automation	GitHub Actions	Jenkins	see above 🟡
Requirements/spec	Sphinx-needs	Latex?	see artefact mapping discussion
Architecture	Sphinx-needs, PlantUML, Draw.IO	EA	see artefact mapping discussion
C++: build system	bazel	cmake	AUTOSAR will elaborate a switch to bazel 🟡
Copyright header (=License)	Apache 2.0	comparable CC NC ❓	❌ Alignment impossible

---

Discussed

Area	S-CORE	AUTOSAR	Alignment
C++	C++17	C++14	AUTOSAR refence implementation is going to use C++17 ✅
C++: formatting	clang-format + custom config	clang-format + google-config	config can be worked out together. Common configuration seems likely ✅
C++: unit testing	gtest + gcovr	gtest	Align version ✅
C++: Detailed Design / Documentation	Doxygen (+import to sphinx needs). Additional keywords not yet defined.	Doxygen for code documentation, with lots of keywords like @param, @returns, @throws, @see, @note etc	Detailed analysis will be required, but looks similar. S-CORE does not have this level of detail defined yet. Sphinx-needs vs FC-Design see artefact mapping discussion. 🟡
C++: dependencies	gtest + google_benchmark (no package manager, since there is currently no demand)	yocto recipes for gtest + boost	AUTOSAR to identify which libraries are required for the reference implementation 🟡
C++: compiler	gcc, clang	clang	AUTOSAR to check if they can use gcc in addition, see e.g. #731🟡
C++: code analysis	clang-tidy, not-yet-defined-tool for MISRA	cppcheck, proprietary checker	AUTOSAR to check if they can use clang-tidy for the reference implementation 🟡
C++: coding rules + style	MISRA + Google/Core	MISRA + Custom	Alignment likely. S-CORE has not properly defined this level of detail yet. Except e.g. function names! Separate config required 🟡
Run tests on virtual OS	Current(!): Linux (native?) + QNX.8 (VM/docker)	Linux 5.15	AUTOSAR to check whether to support QNX with the reference implementation 🟡
building full images incl OS	out of scope?	yocto for building full images incl reference implementation	S-CORE to check whether building images is in scope 🟡

Not yet discussed

Area	S-CORE	AUTOSAR	Alignment
Supported development environment	not sure	Ubuntu 16.04	❓Alignment possible?!
Linking code to requirements	Via req-Id	Via @uptrace{req, hash} and testtrace	Alignment likely
Python	3.13	3.4	Alignment likely
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
dependency licenses check	via eclipse dash	none?	-

Non-tools

Not relevant here, just so we have a place to move stuff instead of deleting it

• review guidelines & checklists

[aschemmel-tech]

I am not sure if we also need to talk about the topic that S-CORE components also may use Rust for development (still providing adittionally a C++ interface). But if these are used in AUTOSAR maybe there is a build environment topic?

[AlexanderLanin]

Will Rust components provide a C, C++ and/or Rust interface in S-CORE?