dev-process/toolstack/toolstack.md

Toolstack – slohmaier Dev Process

Kompletter Open-Source-Toolstack fuer ASPICE 4.0 und ISO 26262 konforme Embedded-Entwicklung.

---

Uebersicht

Kategorie	Tool	Bemerkung
Source Control	Gitea (self-hosted)	tea CLI fuer Kommandozeile, VS Code Integration
Requirements	Doorstop (Markdown-Modus)	Requirements als .md mit PlantUML eingebettet
Architektur-Design	Doorstop + PlantUML	SA / SWA / SWD als .md mit Mapping per links: (ASPICE SYS.3 / SWE.2 / SWE.3)
Diagramme	PlantUML	Eingebettet in Markdown, gerendert von Gitea und VS Code
MISRA	Cppcheck + MISRA-Addon	Kostenlos, Deviation Permits/Records via Doorstop
Coverage	gcov/lcov	Bis ASIL-B; MCDC-Star fuer ASIL-C/D
Unit Tests	CppUTest oder Google Test	Je nach Projekt
Static Analysis	Cppcheck, clang-tidy	Cppcheck auch fuer MISRA
Build	SCons, CMake	Je nach Projekt
Compiler	GCC ARM	Eigene Qualifizierung; Ferrocene fuer Rust
CI	Gitea Actions	Pipeline im Monorepo unter .gitea/workflows/
Open Source Analyse	ScanCode, FOSSology	Lizenz-Compliance
KI-Unterstuetzung	Continue.dev + Ollama	VS Code Extension, lokal, kein Cloud-Datenschutzproblem
Dokumentenexport	pandoc	Markdown nach PDF
Editor	VS Code	Primaerer Editor fuer alles

---

Source Control: Gitea

Gitea ist eine self-hosted Git-Plattform. Leichtgewichtig, laeuft auf jeder Hardware.

• Web-UI fuer PRs, Reviews, Issues
• Gitea Actions fuer CI/CD (kompatibel mit GitHub Actions Syntax)
• PlantUML-Rendering in Markdown (per PlantUML-Server)
• tea CLI fuer Kommandozeilen-Workflows
• Branch Protection und Approval-Workflows

Setup-Anleitung: gitea-aspice-setup.md

---

Requirements: Doorstop (Markdown-Modus)

Doorstop verwaltet Requirements als .md-Dateien mit YAML-Frontmatter. Kein proprietaeres Format, alles lesbar in jedem Editor.

Vorteile:

• Requirements sind Markdown, versioniert in Git
• PlantUML-Diagramme direkt im Requirement eingebettet
• Traceability-Pruefung per CLI: doorstop check
• Report-Generierung: doorstop publish all docs/traceability/
• Gitea rendert alles direkt (Markdown + PlantUML)

Requirement-Format:

---
active: true
level: 1.0
links:
  - SYS-001: abc123
---

# SWE-001: Titel

Beschreibung mit eingebettetem PlantUML.

---

Architektur-Design: Doorstop + PlantUML

Architektur-Elemente sind ebenfalls Doorstop-Dokumente, nur mit eigenen Prefixen:

Prefix	Ebene	ASPICE	Verzeichnis
SA	System Architectural Design	SYS.3	arch/sys/
SWA	Software Architectural Design	SWE.2	arch/swe/
SWD	Software Detailed Design	SWE.3	arch/swd/

Mapping auf Anforderungen per links: im YAML-Frontmatter — identisch zur Requirements-Verlinkung. Doorstop verifiziert in beide Richtungen: keine verwaisten Anforderungen, keine verwaisten Architektur-Elemente.

Verifikation in der CI:

doorstop check                              # bidirektional, schlaegt fehl bei Luecken
doorstop publish all docs/traceability/     # Traceability-Matrix erzeugen

Vorlagen unter dev-process/vorlagen/:

• SA-vorlage.md — System Architecture Element
• SWA-vorlage.md — Software Architecture Element

SWD wird nur fuer ASIL-C/D zwingend gefuehrt; fuer QM/A/B reichen Code + Header-Kommentare.

---

Diagramme: PlantUML

PlantUML-Diagramme werden direkt in Markdown eingebettet. Kein separates Tool, kein Export.

Rendering:

• Gitea: Automatisch via PlantUML-Server (Konfiguration in app.ini)
• VS Code: PlantUML-Extension (jebbs.plantuml) fuer Live-Preview
• Export: pandoc mit PlantUML-Filter fuer PDF

---

MISRA: Cppcheck + MISRA-Addon

Cppcheck mit MISRA-Addon prueft C-Code auf MISRA-Konformitaet. Kostenlos, laeuft in der CI-Pipeline.

cppcheck --addon=misra --error-exitcode=1 src/

Deviation Permits und Records werden als Markdown-Dateien im misra/-Verzeichnis verwaltet. Vorlagen unter dev-process/vorlagen/.

---

Coverage

ASIL	Tool	Methode
A–B	gcov/lcov	Statement + Branch Coverage
C–D	MCDC-Star	MC/DC Coverage

Coverage-Reports werden in der CI generiert und unter tests/results/ abgelegt.

---

Unit Tests

CppUTest oder Google Test, je nach Projektanforderung.

• Tests unter tests/unit/
• Ergebnisse unter tests/results/
• CI fuehrt Tests bei jedem Push aus

---

Static Analysis

Tool	Zweck
Cppcheck	Allgemeine statische Analyse + MISRA
clang-tidy	Modernisierung, Stil, Bugs

Beide laufen in der CI-Pipeline.

---

Build: SCons / CMake

Je nach Projekt SCons oder CMake. Cross-Compilation fuer ARM-Targets.

---

Compiler

Compiler	Sprache	Qualifizierung
GCC ARM	C/C++	Eigene Qualifizierung nach ISO 26262
Ferrocene	Rust	Zertifizierter Rust-Compiler fuer Safety

---

CI: Gitea Actions

Pipeline-Datei: .gitea/workflows/validate.yml

Schritte bei jedem Push/PR:

1. Doorstop-Konsistenz pruefen
2. MISRA-Check
3. Unit Tests
4. Coverage
5. Traceability-Report generieren

Syntax kompatibel mit GitHub Actions.

---

Open Source Analyse

Tool	Zweck
ScanCode	Lizenz-Erkennung in Quellcode
FOSSology	Lizenz-Compliance-Analyse

Wichtig fuer Automotive: Lizenz-Compliance muss dokumentiert sein.

---

KI-Unterstuetzung: Continue.dev + Ollama

Continue.dev als VS Code Extension mit Ollama als lokalem Backend.

• Kein Cloud-Service, alle Daten bleiben lokal
• Kein Datenschutzproblem mit Kundendaten
• Unterstuetzung beim Code-Schreiben, Reviews, Dokumentation

---

Dokumentenexport: pandoc

pandoc dokument.md -o dokument.pdf --pdf-engine=xelatex

Alle Dokumente in Markdown, Export nach PDF fuer Kunden und Audits.

---

VS Code Extensions

Extension	Zweck
PlantUML (jebbs.plantuml)	PlantUML-Preview
Markdown All in One	Markdown-Editing
GitLens	Git-History, Blame
YAML (redhat.vscode-yaml)	YAML-Validierung
Continue.dev	KI mit Ollama