Stefan Lohmaier
6e458ae76f
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
149 lines
4.6 KiB
Markdown
149 lines
4.6 KiB
Markdown
---
|
|
active: true
|
|
level: 1.0
|
|
links:
|
|
- SWE-XXX: [hash]
|
|
---
|
|
|
|
# SWA-XXX: [Komponenten-Name]
|
|
|
|
> **Software Architectural Design Element (ASPICE SWE.2).**
|
|
> Beschreibt eine Software-Komponente und ihr Mapping auf Software-Anforderungen.
|
|
|
|
| Feld | Wert |
|
|
|----------|-------------------------------|
|
|
| Projekt | [Projektname] |
|
|
| Datum | [YYYY-MM-DD] |
|
|
| Version | [1.0] |
|
|
| Status | [Entwurf / Freigegeben] |
|
|
| ASIL | [QM / A / B / C / D] |
|
|
| Autor | [Name] |
|
|
| Parent | [SA-XXX, falls vorhanden] |
|
|
|
|
---
|
|
|
|
## 1. Verantwortung
|
|
|
|
[Ein bis zwei Saetze: Was tut diese Komponente? Wo ist die Abgrenzung zu Nachbar-Komponenten?]
|
|
|
|
## 2. Statische Sicht
|
|
|
|
### 2.1 Komponentendiagramm
|
|
|
|
```plantuml
|
|
@startuml
|
|
package "[Komponenten-Name]" {
|
|
[Submodul A]
|
|
[Submodul B]
|
|
}
|
|
[Submodul A] --> [Submodul B]
|
|
[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt
|
|
@enduml
|
|
```
|
|
|
|
### 2.2 Eingebettete / verwendete Komponenten
|
|
|
|
| Komponente | Verweis | Verwendung |
|
|
|---------------|----------|--------------------------|
|
|
| [Name] | SWA-YYY | [wofuer] |
|
|
|
|
## 3. Schnittstellen
|
|
|
|
### 3.1 Bereitgestellte Schnittstelle (Provided)
|
|
|
|
```c
|
|
/**
|
|
* @brief [Kurzbeschreibung]
|
|
* @param [name] [Bedeutung, Wertebereich]
|
|
* @return [Status / Wert]
|
|
* @pre [Vorbedingung]
|
|
* @post [Nachbedingung]
|
|
*/
|
|
Status component_init(const Config* cfg);
|
|
```
|
|
|
|
| Funktion | Zweck | Pre-Condition | Post-Condition |
|
|
|------------------|----------------------|-----------------------|------------------------|
|
|
| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit |
|
|
| component_send | Daten senden | initialisiert | Daten in TX-Buffer |
|
|
|
|
### 3.2 Benoetigte Schnittstelle (Required)
|
|
|
|
| Schnittstelle | Bereitgestellt von | Zweck |
|
|
|-------------------|--------------------|-----------------------|
|
|
| ILogger::log() | LoggerComponent | Diagnose / Tracing |
|
|
| IClock::now() | ClockComponent | Zeitstempel |
|
|
|
|
## 4. Dynamisches Verhalten
|
|
|
|
### 4.1 Sequenzdiagramm (kritischer Ablauf)
|
|
|
|
```plantuml
|
|
@startuml
|
|
participant App
|
|
participant "[Komponente]" as C
|
|
participant HW
|
|
App -> C: init(cfg)
|
|
C -> HW: configure
|
|
HW --> C: ok
|
|
C --> App: STATUS_OK
|
|
@enduml
|
|
```
|
|
|
|
### 4.2 Zustandsdiagramm (falls zutreffend)
|
|
|
|
```plantuml
|
|
@startuml
|
|
[*] --> Uninitialized
|
|
Uninitialized --> Ready : init()
|
|
Ready --> Busy : send()
|
|
Busy --> Ready : tx_done
|
|
Ready --> Error : fault
|
|
Error --> Ready : reset()
|
|
@enduml
|
|
```
|
|
|
|
## 5. Ressourcen-Bedarf
|
|
|
|
| Ressource | Worst-Case | Methode der Bestimmung |
|
|
|-------------------|--------------|-----------------------------|
|
|
| Stack | [z.B. 256 B] | [Messung / statische Analyse] |
|
|
| Heap | [z.B. 0 B] | [keine Heap-Nutzung] |
|
|
| Flash | [z.B. 4 KB] | [Map-File des Linkers] |
|
|
| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] |
|
|
| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] |
|
|
| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] |
|
|
|
|
## 6. Fehlerverhalten
|
|
|
|
| Fehlerfall | Erkennung | Reaktion |
|
|
|-----------------------|-------------------|---------------------------|
|
|
| Ungueltige Konfig | Parameter-Check | Status STATUS_EINVAL |
|
|
| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT |
|
|
| Buffer voll | Check vor Schreiben | STATUS_NOSPACE |
|
|
|
|
## 7. Designentscheidungen
|
|
|
|
| Entscheidung | Alternative(n) | Begruendung |
|
|
|------------------------|------------------|--------------------------|
|
|
| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] |
|
|
| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] |
|
|
|
|
## 8. Mapping auf Anforderungen
|
|
|
|
| Anforderung | Wie abgedeckt | Verifikations-Test |
|
|
|---------------|----------------------------------------------|----------------------------|
|
|
| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY |
|
|
| SWE-YYY | [...] | TST-UNIT-YYY |
|
|
|
|
Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben.
|
|
|
|
## 9. Detail-Design
|
|
|
|
Detail-Design (ASPICE SWE.3) wird ab ASIL-C separat in `arch/swd/SWD-XXX.md` gefuehrt.
|
|
Fuer ASIL-A/B und QM ist Code + Header-Kommentare ausreichend.
|
|
|
|
---
|
|
|
|
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).*
|