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
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,148 @@
|
||||
---
|
||||
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).*
|
||||
Reference in New Issue
Block a user