Files

T

Stefan Lohmaier 6e458ae76f Initial commit: slohmaier Dev Process v1.0

ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams.

Inhalte:
- README mit hybrider Format-Strategie (Word + Markdown)
- Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc)
- Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA)
- Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan,
  SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records)
- Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001-
  konformer Document Control, Formatvorlagen, Auto-Verzeichnissen
- Build-Scripts (build_word_template.py, generate_word_vorlagen.sh)
- gitea-aspice-setup.md, V-Modell-Infografik

2026-05-11 13:40:51 -07:00

3.3 KiB

Raw Blame History

active, level, links

active

level

links

true

1.0

SYS-XXX

hash

SA-XXX: [Element-Name]

System Architectural Design Element (ASPICE SYS.3). Beschreibt ein Element der System-Architektur und sein Mapping auf System-Anforderungen.

Feld	Wert
Projekt	[Projektname]
Datum	[YYYY-MM-DD]
Version	[1.0]
Status	[Entwurf / Freigegeben]
ASIL	[QM / A / B / C / D]
Autor	[Name]

1. Verantwortung

[Was tut dieses Element? Ein bis zwei Saetze. Welcher Zweck im Gesamtsystem.]

2. System-Kontext

[PlantUML-Diagramm: dieses Element im Verhaeltnis zu Nachbarsystemen / Umgebung.]

@startuml
!define COMPONENT(x) component "x" as x
COMPONENT([Element])
[Element] --> [Nachbarsystem A] : Schnittstelle X
[Nachbarsystem B] --> [Element] : Schnittstelle Y
@enduml

3. Allokation

Anforderung	Allokation auf	Bemerkung
SYS-XXX	dieses Element	[vollstaendig / teilweise]
SYS-YYY	dieses Element	[Begruendung]

Allokations-Regel: jede verlinkte System-Anforderung muss eindeutig auf HW, SW oder Mechanik abgebildet werden.

4. Schnittstellen zur Umgebung

Schnittstelle	Richtung	Typ	Bemerkung
[Name]	in / out / io	[CAN / SPI / GPIO / ...]	[Protokoll-Verweis]

5. Subkomponenten / Aufteilung

[Falls dieses System-Element aus mehreren Subkomponenten besteht: kurze Auflistung mit Verweis auf weitere SA- oder SWA-Elemente.]

Subkomponente	Realisierung	Verweis
[Name]	[HW / SW / Mechanik]	SWA-XXX / SA-YYY

6. Dynamisches Verhalten

[PlantUML-Sequenz oder State-Diagramm fuer kritische Ablaeufe.]

@startuml
actor Nutzer
Nutzer -> [Element]: Anforderung
[Element] -> [Nachbar]: weiterleiten
[Nachbar] --> [Element]: Antwort
[Element] --> Nutzer: Ergebnis
@enduml

7. Nichtfunktionale Eigenschaften

Aspekt	Anforderung / Zielwert
Worst-Case Timing	[z.B. < 10 ms Reaktionszeit]
Speicherbedarf	[z.B. < 64 KB Flash]
Stromaufnahme	[z.B. < 200 mA bei 12 V]
Umgebungsbedingungen	[Temperatur, EMV]
Sicherheitsziel	[Verweis auf SG-XXX, falls vorhanden]

8. Designentscheidungen

Entscheidung	Alternativen	Begruendung
[Was]	[Was sonst noch erwogen wurde]	[Warum diese Wahl]

9. Verifikation

Anforderung	Verifikations-Methode	Test-ID
SYS-XXX	[Review / Test / Analyse]	TST-SYS-XXX

Jede in den links referenzierte System-Anforderung muss mindestens eine Verifikations-Methode haben.

Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).

3.3 KiB Raw Blame History