Entscheidungsprotokoll & Projekterkenntnisse28 Entscheidungen: 12 ADRs + 16 aus Projekterkenntnissen

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-Ausführungspläne als operative Aufschlüsselung

Warum sie gewinnt: Der Master-Plan liefert strategischen Kontext (Architektur, BOM, Demos), den Ausführungspläne nicht abdecken.

Cost 1 | Time 1 | Safety 1 | Resume 1

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

Warum sie gewinnt: Das Git-versionierte Rechercheprotokoll hält Quellen und Quellcode zusammen. Es ist durchsuchbar und prüfbar.

Cost 1 | Time 1 | Safety 1 | Resume 2

Entscheidung: Fortschrittsübersicht, Problemprotokoll, Entscheidungsprotokoll und Checkliste zur Freigabereife zu MAN.3 hinzufügen

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

Cost 2 | Time 2 | Safety 3 | Resume 3

Entscheidung: 3x STM32G474RE Nucleo-64 Boards für CVC, FZC und RZC Zonensteuergeräte. 3x FDCAN, 5x ADC, CORDIC+FMAC, 170 MHz Cortex-M4F.

Warum sie gewinnt: Gewinnt CAN-FD, extra ADCs für Dual-Sensor-Plausibilität 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 über 3 STM32 ECUs.

Warum sie gewinnt: Breite Automotive-Erfahrung, Konformität mit ASPICE SWE.2/SWE.3 und Hardwareabstraktion für SIL-Tests. Hohe Relevanz für Embedded-Rollen gegenüber einer reinen Bare-Metal-Demo.

Cost 1 | Time 2 | Safety 1 | Resume 3

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

Warum sie gewinnt: Einzige Option mit 100% Code-Wiederverwendung. Python-can zerstört die AUTOSAR-Portabilitätsgeschichte. Vector CANoe kostet $10K+.

Cost 1 | Time 1 | Safety 1 | Resume 3

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

Warum sie gewinnt: 4-7 Tage für funktionierendes SOME/IP Demo mit BMW/COVESA-Kredibilität. Eigene Reimplementierung verschwendet 4-8 Wochen.

Cost 1 | Time 1 | Safety 1 | Resume 2

Entscheidung: Drei simulierte Steuergeräte (BCM, ICU, TCU) in Docker-Containern mit virtuellen CAN-Schnittstellen (vcan/vxcan) ausführen.

Warum sie gewinnt: Ähnlicher Aufwand wie systemeigene Prozesse, aber mit Isolation, Reproduzierbarkeit und Portabilität in CI/CD. QEMU benötigt deutlich mehr Einrichtungsaufwand.

Cost 1 | Time 1 | Safety 3 | Resume 2

Entscheidung: Unity (ThrowTheSwitch) für C-Unit-Tests, integrierte CCS-Tests für TMS570 und pytest für Python-Gateway und Cloud verwenden.

Warum sie gewinnt: Reines C und kurze Einrichtung gegenüber gtest. CMock erzeugt Mocks automatisch; CUnit wird nicht mehr gepflegt.

Cost 1 | Time 1 | Safety 3 | Resume 2

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

Warum sie gewinnt: Null-Kosten-Baseline. CAN FD fügt 8-13 Tage für nicht benötigte 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 und Grafana für Cloud-Telemetrie verwenden; Nachrichten für die kostenlose Stufe bündeln.

Warum sie gewinnt: Geringe monatliche Kosten und hohe Relevanz im Automotive-Umfeld. Azure wäre deutlich teurer; reiner Eigenbetrieb zeigt weniger Cloud-Integration.

Entscheidung: Immer in Reihenfolge härten: Notfall-Fixes → Auth/Missbrauchsschutz → Zugriffskontrolle → API-Härtung → 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 über 10 Phasen.

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

Entscheidung: Immer gegen die CI-Tool-Version (cppcheck 2.13) validieren bevor lokale Ergebnisse (2.17) als gültig 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 Inkompatibilitäten 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 für Unity-Tests — .c-Dateien includen, nicht linken; Standard Embedded TDD
• Mock-State muss in setUp() gelöscht werden — ALLE Mock-Globals nullen, keine Ausnahmen
• Header-Guard-Kollisionen über Testdateien (DEM_H, E2E_H) — Guards mit TEST_-Namespace prefixen

Entscheidung: Heartbeat Alive-Counter wrapt bei 4-bit (0-15) gemäß 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 für 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 über 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 prüfen
• 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 überspringen Entwickler Tests unter Zeitdruck. Hook-erzwungenes TDD produzierte 16 Module mit 1.067 Tests und null übersprungene Module.

• Table-driven State Machines und Dual-Sensor-Plausibilität über alle BSW-Module bewährt
• E2E als standalone Modul: abhängigkeitsfrei, wiederverwendbar über physische und simulierte ECUs
• Phasenbasierte Ausführung mit Status-Tabelle hält Momentum und verhindert Scope Creep

Entscheidung: Menschlich verfasste Review-Kommentare mit HITL-LOCK-Markern schützen. Why/Tradeoff/Alternative-Struktur verwenden. Jeden Review-Kommentar für CM-Nachvollziehbarkeit datieren.

Was wir gelernt haben: AI hat menschliche Review-Kommentare ohne Marker umformatiert und verschoben. 443+ HITL-Kommentare über 29 Docs wären ohne Schutz nicht verwaltbar.

• HITL-LOCK-Marker sind unveränderlich nach Setzen — AI darf gesperrte Inhalte nie bearbeiten
• Anforderungsbezogene Lessons-Learned-Dateien (SYS-NNN) halten Erkenntnisse mit ihrer Quelle verknüpft
• Konsolidierter Lessons-Learned-Ordner besser als verstreute Einzel-Doc-Dateien

Entscheidung: Git + Markdown deckt 90% der DOORS/Polarion/Jama-Funktionalität bei 0% Lizenzkosten. ADR-Format mit 4-Dimensionen-Scoring ermöglicht entscheidungsübergreifenden 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 willkürlicher Klassifizierung
• Zonale Architekturentscheidung durch Lebenslauf-Wert + Lernmöglichkeit getrieben, nicht nur technisch

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

Was wir gelernt haben: VBAT-Fault-Injection auf ungeschützten Nucleo-Boards riskiert MCU-Zerstörung. Eine EUR 0,10 Zener-Diode verhindert EUR 16 Board-Ersatz.

• DIY HIL ist legitim über 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-Bänken skaliert auf Budget-Hardware herunter

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

Was wir gelernt haben: Initialer Entwurf nahm SPI-Bus-Unabhängigkeit 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 — stärkt das Safety-Argument
• DMA/Treiber-Komplexität kein gültiges Argument gegen SPI1+SPI2 — Config ist triviales Copy-Paste
• Separate SPI-Busse nur gerechtfertigt wenn ASIL-Dekomposition bewiesene Unabhängigkeit erfordert

Entscheidung: CI muss Merge bei Traceability-Lücken 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-Prüfung sie fand.

• trace-gen.py validiert SG → FSR → TSR → SSR → Code → Test Kettenvollständigkeit
• Verwaiste Requirements (keine Implementierung) und verwaiste Tests (kein Requirement) beide erkannt
• Traceability-Report bei jedem CI-Lauf generiert — Assessoren können jederzeit prüfen

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 führte zu Requirements ohne Safety-Goal-Bezug — verschwendeter Aufwand.

• S3/E4/C3 = ASIL D für Drive-by-Wire — die Matrixwerte sind eindeutig, keine Debatte nötig
• Safety Goals brauchen FTTI-Begründung: detect_time + react_time aus konkreten Mechanismen abgeleitet
• GSN (Goal Structuring Notation) macht die Argumentstruktur sichtbar und auditierbar

Entscheidung: HAL-Abstraktion für Unit-Testing entworfen ist die gleiche Abstraktion die SIL-Simulation ermöglicht. SocketCAN nutzt identische API für vcan und echtes CAN — nur Interface-Name ändern.

Was wir gelernt haben: POSIX SocketCAN-Backend wurde für SIL hinzugefügt, stellte sich aber als exakt gleiche Abstraktionsgrenze heraus die wir für 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 unterdrücken
• 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: Zufällige Fault-Injection produzierte nicht-reproduzierbare Ergebnisse. ML-Anomalie-Scores steckten bei Baseline fest weil Schwellwerte verschiedene Betriebszustände nicht berücksichtigten.

• 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 nötig
• Controller-Viewer-Lock-Pattern verhindert Multi-User-Konflikte in Live-Demo

Entscheidung: SIL-Tests finden Integrationsprobleme die Mocks nicht können: ECU-zu-ECU-Kommunikation, E2E-Schutz, Fault-State-Übergänge. Nächtlich in CI ausführen. Unbekannte Test-Schritte müssen laut fehlschlagen.

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

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

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

Was wir gelernt haben: MG996R als 360 Grad gelistet war tatsächlich 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 — Gehäuse vs Montagemethode vor Bestellung prüfen
• Lieferzeit für Automotive-Grade-Komponenten kann 8-12 Wochen sein — früh bestellen, mit Commercial Grade prototypen
• BOM muss enthalten: volle Teilenummer, Hersteller, Distributor-Link, Datenblatt-Link, Gehäusetyp