---
active: true
level: 1.0
links:
  - 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.]

```plantuml
@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.]

```plantuml
@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).*