Decision Log & Lessons Learned28 Entscheidungen: 12 ADRs + 16 aus Lessons Learned

Cost 1 | Time 1 | Safety 1 | Resume 2

Entscheidung: Dokumentation unter docs/aspice/ nach Prozessbereich organisieren

Warum sie gewinnt: Dateibasiertes ALM in Git bietet assessor-freundliche Struktur ohne Kosten mit voller Versionskontrolle.

Cost 1 | Time 1 | Safety 1 | Resume 1

Entscheidung: Master-Plan als einzigen strategischen Plan beibehalten, ASPICE-Ausfuehrungsplaene als operative Aufschluesselung

Warum sie gewinnt: Der Master-Plan liefert strategischen Kontext (Architektur, BOM, Demos), den Ausfuehrungsplaene nicht abdecken.

Cost 1 | Time 1 | Safety 1 | Resume 1

Entscheidung: Alle externen Referenzen und Recherche-Notizen in docs/research/ zentralisieren

Warum sie gewinnt: Git-versioniertes Research-Log haelt die Herkunft beim Codebase. Durchsuchbar und auditierbar.

Cost 1 | Time 1 | Safety 1 | Resume 2

Entscheidung: Fortschritts-Dashboard, Issue-Log, Decision-Log und Gate-Readiness-Checkliste zu MAN.3 hinzufuegen

Warum sie gewinnt: Markdown-Tracking-Dateien im Repo erfuellen ASPICE-Nachweisanforderungen und werden mit dem Code baselined.

Cost 2 | Time 2 | Safety 3 | Resume 3

Entscheidung: 3x STM32G474RE Nucleo-64 Boards fuer CVC, FZC und RZC Zonensteuergeraete. 3x FDCAN, 5x ADC, CORDIC+FMAC, 170 MHz Cortex-M4F.

Warum sie gewinnt: Gewinnt CAN-FD, extra ADCs fuer Dual-Sensor-Plausibilitaet und HW-Beschleuniger vs F446RE. Arduino Mega disqualifiziert (8-bit/8KB/kein CAN).

Cost 1 | Time 2 | Safety 3 | Resume 3

Entscheidung: Eigenes AUTOSAR-Classic-inspiriertes BSW: MCAL, EAL, Services, RTE — 16 Module, ~5.000 LOC geteilt ueber 3 STM32 ECUs.

Warum sie gewinnt: 16+ Automotive-Lebenslauf-Keywords, ASPICE SWE.2/SWE.3 Compliance, HW-Abstraktion fuer SIL-Tests. 10/10 Lebenslauf-Impact vs 3/10 bare-metal.

Cost 1 | Time 2 | Safety 1 | Resume 3

Entscheidung: POSIX SocketCAN API als MCAL-Schicht fuer 3 simulierte ECUs in Docker — 100% Code-Wiederverwendung zwischen physischen und simulierten ECUs.

Warum sie gewinnt: Einzige Option mit 100% Code-Wiederverwendung. Python-can zerstoert die AUTOSAR-Portabilitaetsgeschichte. Vector CANoe kostet $10K+.

Cost 1 | Time 1 | Safety 1 | Resume 3

Entscheidung: vsomeip (COVESA/BMW) fuer serviceorientierte Kommunikation zwischen simulierten ECUs und Pi Gateway.

Warum sie gewinnt: 4-7 Tage fuer funktionierendes SOME/IP Demo mit BMW/COVESA-Kredibilitaet. Eigene Reimplementierung verschwendet 4-8 Wochen.

Cost 1 | Time 1 | Safety 1 | Resume 2

Entscheidung: 3 simulierte ECUs (BCM, ICU, TCU) in Docker-Containern mit virtuellen CAN (vcan/vxcan) Interfaces ausfuehren.

Warum sie gewinnt: Gleicher 1-2 Tage Aufwand wie native Prozesse, aber mit Isolation, Reproduzierbarkeit und CI/CD-Portabilitaet. QEMU kostet 3-15x mehr Setup.

Cost 1 | Time 1 | Safety 3 | Resume 2

Entscheidung: Unity (ThrowTheSwitch) fuer C Unit-Tests, CCS built-in fuer TMS570, pytest fuer Python Gateway/Cloud.

Warum sie gewinnt: Reines C, 2-4 Stunden Setup vs 2-4 Tage gtest. CMock generiert Mocks automatisch. CUnit ist aufgegeben (2018).

Cost 1 | Time 1 | Safety 3 | Resume 2

Entscheidung: CAN 2.0B bei 500 kbps fuer gesamte Inter-ECU-Kommunikation. TMS570 DCAN erfordert klassisches CAN. 35% Busauslastung — kein Bandbreitendruck.

Warum sie gewinnt: Null-Kosten-Baseline. CAN FD fuegt 8-13 Tage fuer nicht benoetigte Bandbreite hinzu. Ethernet erfordert 3 neue MCU-Boards + 6-10 Wochen.

Cost 1 | Time 1 | Safety 1 | Resume 3

Entscheidung: AWS IoT Core (MQTT) + Amazon Timestream (Zeitreihen-DB) + Grafana fuer Cloud-Telemetrie, gebatcht 1 msg/5sec fuer Free Tier.

Warum sie gewinnt: ~$4-7/Monat mit hoechster Automotive-Kredibilitaet (Mercedes, VW, Toyota nutzen AWS). Azure ist 4-5x teurer. Self-hosted fehlt Lebenslauf-Wert.

Entscheidung: Immer in Reihenfolge haerten: Notfall-Fixes → Auth/Missbrauchsschutz → Zugriffskontrolle → API-Haertung → Monitoring → Verifikations-Gate. Nie zu erweiterten Features springen bevor Basics gesichert.

Was wir gelernt haben: Sprung zu OAuth und reCAPTCHA vor solidem Auth, Rate Limiting und CSRF verursachte erhebliche Nacharbeit ueber 10 Phasen.

• Fail-Closed-Pattern: bei fehlender Config ablehnen, nie Auth still ueberspringen
• Generisches SMTP von Anfang an — Vendor-SDK-Lock-in (Resend) kostete mehrere Phasen zum Entfernen
• Marketing-Claims gegen Code pruefen VOR Launch — Zahlen veralten, Absolutaussagen sind falsch

Entscheidung: Immer gegen die CI-Tool-Version (cppcheck 2.13) validieren bevor lokale Ergebnisse (2.17) als gueltig angenommen werden. Tool-Versionen in CI-Config pinnen.

Was wir gelernt haben: cppcheck 2.13 (CI/Ubuntu apt) vs 2.17 (lokal/pip) hatte 6 Inkompatibilitaeten die erst in CI nach Push auftraten.

• Keine #-Kommentare in suppressions.txt — cppcheck 2.13 kann sie nicht parsen
• .gitignore blockiert suppressions.txt — !-Ausnahme verwenden bei Directory-Pattern-Ignores
• 1.536 auf 0 Violations an 1 Tag mit systematischer Triage: mandatory zuerst, required danach, advisory zuletzt

Entscheidung: stdint.h Fixed-Width-Typen (uint32_t) in allem host-kompiliertem Testcode verwenden. Nie auf AUTOSAR-Plattformtypen vertrauen die ILP32 annehmen.

Was wir gelernt haben: LP64 (Host) vs ILP32 (Target): uint32 mappte auf unsigned int am Target aber unsigned long am Host, verursachte 99 Type-Mismatch-Fehler in CI.

• Source-Inclusion-Pattern fuer Unity-Tests — .c-Dateien includen, nicht linken; Standard Embedded TDD
• Mock-State muss in setUp() geloescht werden — ALLE Mock-Globals nullen, keine Ausnahmen
• Header-Guard-Kollisionen ueber Testdateien (DEM_H, E2E_H) — Guards mit TEST_-Namespace prefixen

Entscheidung: Heartbeat Alive-Counter wrapt bei 4-bit (0-15) gemaess AUTOSAR E2E Profil 1, nicht 8-bit. Modulare Arithmetik und einzelner Monitor pro ECU verwenden.

Was wir gelernt haben: Doppelte Heartbeat-Monitore und 8-bit-Wrap-Annahme verursachten persistentes UI-Flackern im SIL-Demo-Dashboard.

• Docker Compose v2: 'docker compose' (Leerzeichen) nicht 'docker-compose' (Bindestrich) — bricht Scripts still
• NET_RAW-Capability fuer CAN in Containern erforderlich — aus Fehlermeldungen nicht ersichtlich
• RTE_MAX_SIGNALS zu klein verursacht stillen Init-Fehler — Signalanzahl beim Start validieren

Entscheidung: Jeden geteilten Parameter (CAN-Bit-Timing, Sensor-Specs, Pin-Zuweisungen) in genau einem kanonischen Dokument definieren. Alle anderen Docs referenzieren, nie kopieren.

Was wir gelernt haben: CAN-Bit-Timing (87,5% vs 80% Abtastpunkt) war inkonsistent ueber 4 Dokumente. ACS723-Empfindlichkeit war in 5 Stellen falsch.

• CAN-IDs am meisten duplizierte Daten — projektweites Grep nach jeder Aenderung um Mismatches zu finden
• MG996R Servo: 180 Grad, nicht 360 Grad (Amazon BOM-Listing-Fehler) — immer Datenblatt pruefen
• Cross-Doc-Review-Checkliste findet was Einzel-Review verpasst

Entscheidung: Schreibzugriffe auf Firmware-.c-Quelldateien blockieren wenn keine entsprechende test_*.c existiert. AUTOSAR BSW Schicht-Bauordnung erzwingen: MCAL, ECUAL, Services, RTE.

Was wir gelernt haben: Ohne Erzwingung ueberspringen Entwickler Tests unter Zeitdruck. Hook-erzwungenes TDD produzierte 16 Module mit 1.067 Tests und null uebersprungene Module.

• Table-driven State Machines und Dual-Sensor-Plausibilitaet ueber alle BSW-Module bewaehrt
• E2E als standalone Modul: abhaengigkeitsfrei, wiederverwendbar ueber physische und simulierte ECUs
• Phasenbasierte Ausfuehrung mit Status-Tabelle haelt Momentum und verhindert Scope Creep

Entscheidung: Menschlich verfasste Review-Kommentare mit HITL-LOCK-Markern schuetzen. Why/Tradeoff/Alternative-Struktur verwenden. Jeden Review-Kommentar fuer CM-Nachvollziehbarkeit datieren.

Was wir gelernt haben: AI hat menschliche Review-Kommentare ohne Marker umformatiert und verschoben. 443+ HITL-Kommentare ueber 29 Docs waeren ohne Schutz nicht verwaltbar.

• HITL-LOCK-Marker sind unveraenderlich nach Setzen — AI darf gesperrte Inhalte nie bearbeiten
• Pro-Requirement Lessons-Learned-Dateien (SYS-NNN) halten Erkenntnisse mit ihrer Quelle verknuepft
• Konsolidierter Lessons-Learned-Ordner besser als verstreute Einzel-Doc-Dateien

Entscheidung: Git + Markdown deckt 90% der DOORS/Polarion/Jama-Funktionalitaet bei 0% Lizenzkosten. ADR-Format mit 4-Dimensionen-Scoring ermoeglicht entscheidungsuebergreifenden Vergleich.

Was wir gelernt haben: 7-ECU Hybrid-Architektur (4 physisch + 3 simuliert) bewies dass CAN-Bus Hardware nicht von Docker unterscheidet — dateibasierte Tools skalieren genauso.

• Decision-Audit-Script findet undokumentierte Entscheidungen via heuristisches Grep
• Tier-Zuordnung (T1-T4) folgt aus Scores, nicht willkuerlicher Klassifizierung
• Zonale Architekturentscheidung durch Lebenslauf-Wert + Lernmoeglichkeit getrieben, nicht nur technisch

Entscheidung: VBAT-Fault-Injection bei Budget-Hardware ueberspringen — nur GND + Open-Circuit deckt ~70% der Fehlermodi sicher ab. Praeventiven Zener-Schutz auf jedem Kanal.

Was wir gelernt haben: VBAT-Fault-Injection auf ungeschuetzten Nucleo-Boards riskiert MCU-Zerstoerung. Eine EUR 0,10 Zener-Diode verhindert EUR 16 Board-Ersatz.

• DIY HIL ist legitim ueber Hobby-Niveau — 7-ECU AUTOSAR mit 1.067 Tests ist industrierelevant
• Relais-basierte Fault-Injection-Matrix: MUX-Topologie reduziert Relaisanzahl von N*M auf N+M
• Nadelbett-Adapter-Pattern von professionellen HIL-Baenken skaliert auf Budget-Hardware herunter

Entscheidung: 1oo2D auf geteiltem SPI-Bus akzeptabel wenn Erkennungspfad existiert (CRC + Plausibilitaet → sicherer Zustand). Geteilter Bus-Ausfall ist erkannter Multi-Point-Fault. Immer in DFA dokumentieren.

Was wir gelernt haben: Initialer Entwurf nahm SPI-Bus-Unabhaengigkeit an. HITL-Review deckte auf dass geteilter SPI ein Common Cause Failure ist der explizit analysiert werden muss.

• Beide CRCs gleichzeitig fehlerhaft = erkannter Fehler, nicht unerkannt — staerkt das Safety-Argument
• DMA/Treiber-Komplexitaet kein gueltiges Argument gegen SPI1+SPI2 — Config ist triviales Copy-Paste
• Separate SPI-Busse nur gerechtfertigt wenn ASIL-Dekomposition bewiesene Unabhaengigkeit erfordert

Entscheidung: CI muss Merge bei Traceability-Luecken blockieren — Advisory-Checks werden universell ignoriert. Stub-Scripts die CI bestehen geben falsches Vertrauen; Tooling richtig bauen oder ganz weglassen.

Was wir gelernt haben: 4 gebrochene Requirement-Links und 6 ungetestete SWRs waren unsichtbar bis automatisierte Traceability-Pruefung sie fand.

• trace-gen.py validiert SG → FSR → TSR → SSR → Code → Test Kettenvollstaendigkeit
• Verwaiste Requirements (keine Implementierung) und verwaiste Tests (kein Requirement) beide erkannt
• Traceability-Report bei jedem CI-Lauf generiert — Assessoren koennen jederzeit pruefen

Entscheidung: Immer HARA → Safety Goals → FSR → TSR → SSR aufbauen. Bottom-up produziert Rationalisierung, keine Verteidigung. FTTI muss aus Mechanismen abgeleitet werden, nicht geraten.

Was wir gelernt haben: Versuch SSRs vor HARA-Abschluss zu schreiben fuehrte zu Requirements ohne Safety-Goal-Bezug — verschwendeter Aufwand.

• S3/E4/C3 = ASIL D fuer Drive-by-Wire — die Matrixwerte sind eindeutig, keine Debatte noetig
• Safety Goals brauchen FTTI-Begruendung: detect_time + react_time aus konkreten Mechanismen abgeleitet
• GSN (Goal Structuring Notation) macht die Argumentstruktur sichtbar und auditierbar

Entscheidung: HAL-Abstraktion fuer Unit-Testing entworfen ist die gleiche Abstraktion die SIL-Simulation ermoeglicht. SocketCAN nutzt identische API fuer vcan und echtes CAN — nur Interface-Name aendern.

Was wir gelernt haben: POSIX SocketCAN-Backend wurde fuer SIL hinzugefuegt, stellte sich aber als exakt gleiche Abstraktionsgrenze heraus die wir fuer host-basierte Unit-Tests brauchten.

• POSIX-Backend-Dateien sind MISRA-befreit — Regeln 21.5, 21.6, 21.8, 21.10, 17.7 von Tag eins unterdruecken
• vcan-Modul Auto-Load + Fehlerbereinigung bei Container-Neustart verhindert veralteten CAN-State
• 100% Firmware-Code-Wiederverwendung zwischen physischem ECU und Docker-Container validiert die Abstraktion

Entscheidung: Jede Fault-Injection muss einer definierten inject → detect → react → recovery Sequenz folgen. DTC-Broadcasts brauchen Arbitrierungs-Backoff. ML-Anomalie-Baselines variieren pro Betriebszustand.

Was wir gelernt haben: Zufaellige Fault-Injection produzierte nicht-reproduzierbare Ergebnisse. ML-Anomalie-Scores steckten bei Baseline fest weil Schwellwerte verschiedene Betriebszustaende nicht beruecksichtigten.

• DTC-Broadcast braucht randomisierten 0-50ms Backoff um CAN-Bus-Flooding durch gleichzeitige DTCs zu verhindern
• E-STOP-Event-Spam bei Reset — ordentliche Fault-Clear-Sequenz vor Reaktivierung noetig
• Controller-Viewer-Lock-Pattern verhindert Multi-User-Konflikte in Live-Demo

Entscheidung: SIL-Tests finden Integrationsprobleme die Mocks nicht koennen: ECU-zu-ECU-Kommunikation, E2E-Schutz, Fault-State-Uebergaenge. Naechtlich in CI ausfuehren. Unbekannte Test-Schritte muessen laut fehlschlagen.

Was wir gelernt haben: COM TX/RX Bridge Timing-Probleme und E2E-Sequenzzaehler-Mismatches waren in Unit-Tests unsichtbar — tauchten nur in Multi-ECU SIL-Laeufen auf.

• COM TX/RX Bridge ist die kritischste SIL-Komponente — vor Szenarien bauen und testen
• Fail-Closed gilt auch fuer Test-Infrastruktur — unbekannte Steps muessen fehlschlagen, nicht ueberspringen
• Plant-Simulator-Thermikmodell braucht Tuning pro Betriebspunkt, nicht pauschal

Entscheidung: Nie Marktplatz-Listings vertrauen — immer Hersteller-Datenblatt herunterladen und jeden Parameter pruefen. Volle Teilenummer inklusive Variantensuffix in BOM aufnehmen.

Was wir gelernt haben: MG996R als 360 Grad gelistet war tatsaechlich 180 Grad. ACS723-05A vs ACS723-20A haben 4x unterschiedliche Empfindlichkeit (400 vs 100 mV/A). Beide verursachten Nacharbeit.

• SOT-23-Komponenten brauchen Breakout-Boards — Gehaeuse vs Montagemethode vor Bestellung pruefen
• Lieferzeit fuer Automotive-Grade-Komponenten kann 8-12 Wochen sein — frueh bestellen, mit Commercial Grade prototypen
• BOM muss enthalten: volle Teilenummer, Hersteller, Distributor-Link, Datenblatt-Link, Gehaeusetyp