Files

T

Stefan Lohmaier 8ea3f3d8f4 templates-de: German document templates, moved in from ownCloud

The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.

Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.

Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.

Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.

2026-07-31 09:55:33 +02:00

4.6 KiB

Raw Blame History

active, level, links

active

level

links

true

1.0

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

@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)

/**
 * @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)

@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)

@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).

4.6 KiB Raw Blame History