Stefan Lohmaier
247b8311f3
Final German naming cleanup in dev-process: - vorlagen/ -> templates/ - vorlagen-word/ -> templates-word/ - tools/generate_word_vorlagen.sh -> tools/generate_word_templates.sh - *-vorlage.md / *-vorlage.docx -> *-template.md / *-template.docx - Review-Protokoll-vorlage.* -> Review-Minutes-template.* - angebot-vorlage.* -> quote-template.* - angebot-beispiel.html -> quote-example.html All references in README.md, toolstack/toolstack.md, build_word_template.py, and generate_word_templates.sh updated. The master Word style template (slohmaier-doc-template.docx) was already English-named. The dev-process repo is now fully English in both content and structure.
105 lines
3.2 KiB
Markdown
105 lines
3.2 KiB
Markdown
---
|
|
active: true
|
|
level: 1.0
|
|
links:
|
|
- SYS-XXX: [hash]
|
|
---
|
|
|
|
# SA-XXX: [Element name]
|
|
|
|
> **System Architectural Design Element (ASPICE SYS.3).**
|
|
> Describes a system architecture element and its mapping to system requirements.
|
|
|
|
| Field | Value |
|
|
|----------|--------------------------------|
|
|
| Project | [Project name] |
|
|
| Date | [YYYY-MM-DD] |
|
|
| Version | [1.0] |
|
|
| Status | [Draft / Released] |
|
|
| ASIL | [QM / A / B / C / D] |
|
|
| Author | [Name] |
|
|
|
|
---
|
|
|
|
## 1. Responsibility
|
|
|
|
[What does this element do? One or two sentences. Its purpose in the overall system.]
|
|
|
|
## 2. System context
|
|
|
|
[PlantUML diagram: this element in relation to neighbouring systems / environment.]
|
|
|
|
```plantuml
|
|
@startuml
|
|
!define COMPONENT(x) component "x" as x
|
|
COMPONENT([Element])
|
|
[Element] --> [Neighbour A] : interface X
|
|
[Neighbour B] --> [Element] : interface Y
|
|
@enduml
|
|
```
|
|
|
|
## 3. Allocation
|
|
|
|
| Requirement | Allocated to | Notes |
|
|
|---------------|------------------|------------------------------|
|
|
| SYS-XXX | this element | [full / partial] |
|
|
| SYS-YYY | this element | [Rationale] |
|
|
|
|
Allocation rule: every linked system requirement must be unambiguously mapped to HW, SW, or mechanics.
|
|
|
|
## 4. External interfaces
|
|
|
|
| Interface | Direction | Type | Notes |
|
|
|---------------|---------------|-----------------------|-------------------------|
|
|
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protocol reference] |
|
|
|
|
## 5. Subcomponents / breakdown
|
|
|
|
[If this system element consists of subcomponents: short list with references to other SA or SWA elements.]
|
|
|
|
| Subcomponent | Realisation | Reference |
|
|
|---------------|--------------------|-------------------|
|
|
| [Name] | [HW / SW / mechanics] | SWA-XXX / SA-YYY |
|
|
|
|
## 6. Dynamic behaviour
|
|
|
|
[PlantUML sequence or state diagram for critical flows.]
|
|
|
|
```plantuml
|
|
@startuml
|
|
actor User
|
|
User -> [Element]: request
|
|
[Element] -> [Neighbour]: forward
|
|
[Neighbour] --> [Element]: response
|
|
[Element] --> User: result
|
|
@enduml
|
|
```
|
|
|
|
## 7. Non-functional properties
|
|
|
|
| Aspect | Requirement / target value |
|
|
|---------------------|------------------------------|
|
|
| Worst-case timing | [e.g. < 10 ms reaction time] |
|
|
| Memory footprint | [e.g. < 64 KB flash] |
|
|
| Power draw | [e.g. < 200 mA at 12 V] |
|
|
| Environment | [Temperature, EMC] |
|
|
| Safety goal | [Reference to SG-XXX, if any] |
|
|
|
|
## 8. Design decisions
|
|
|
|
| Decision | Alternatives | Rationale |
|
|
|--------------|--------------|-----------|
|
|
| [What] | [What else was considered] | [Why this choice] |
|
|
|
|
## 9. Verification
|
|
|
|
| Requirement | Verification method | Test ID |
|
|
|-------------|---------------------------|-------------------|
|
|
| SYS-XXX | [Review / test / analysis] | TST-SYS-XXX |
|
|
|
|
Every system requirement listed in `links` must have at least one verification method.
|
|
|
|
---
|
|
|
|
*Changes to this architecture element go through a PR with at least 2 technical-review approvals (see SWE Plan).*
|