Dokumenttyp: Software Requirements Specification (SRS), angelehnt an ISO/IEC/IEEE 29148
Methodik: IREB-Grundprinzipien, MASTeR-Satzschablonen, MoSCoW-Priorisierung
Projekt: CanKit.Pro – höhere CAN-Protokollschichten für .NET, aufbauend auf CanKit
Ursprung: verfasst am 2026-07-14 im Vorgänger-Repository
CanKit.Pro.legacy (Bezug: CanKit master @ 36866ff,
Review docs/reviews/2026-07-14-deep-code-review.md)
Status: Entwurf
Systemgrenze. Dieses Dokument entstand, als CanKit.Pro noch ein Fork von CanKit war, und
formuliert Anforderungen deshalb teilweise an CanKit selbst (Ebenen L0/L1). CanKit.Pro ist heute
kein Fork mehr: L0/L1 sind CanKit, werden als NuGet-Pakete
eingebunden und sind hier Randbedingung statt Lieferumfang. Anforderungen an L0/L1 — allen
voran FR-RAW-001..005 (Frame-Ownership) — sind für CanKit.Pro Annahmen über den Upstream;
durchsetzbar sind sie nur upstream. Die tatsächlich in diesem Repository umgesetzten
Anforderungen sind:
Dieses Dokument spezifiziert die Anforderungen an CanKit, um auf der bestehenden Raw-CAN-Bibliothek eine gehärtete Raw-CAN-Dienstebene sowie darauf aufbauende Transport- und Anwendungsprotokoll-Stacks zu realisieren. Es dient als verbindliche Grundlage für Architektur (docs/architecture/arc42-CanKit.Pro.md, parallel in Erstellung), Implementierung und Abnahmetests.
L2 Raw-CAN-Dienstebene (neu zu bauen) – die Härtung und Erweiterung von ICanBus/CanFrame um Multi-Consumer-Demultiplexing, einen verbindlichen Frame-Ownership-Vertrag, TX-Bestätigung, Adressierungs-Helfer und ein einheitliches Threading-Modell je Protokollinstanz.
L3 Transport-Ebene – Fertigstellung von ISO-TP (ISO 15765-2) sowie Neubau von J1939-TP (TP.BAM/TP.CM).
L4 Anwendungsprotokoll-Ebene – UDS (ISO 14229 über ISO-TP), CANopen (CiA 301), J1939-Applikation (SAE J1939/ISO 11783).
Nicht im Scope: Neuimplementierung von L0 (Vendor-Adapter) und der bereits vorhandenen L1-Kernfunktionalität (ICanBus, CanFrame, CanRegistry) – diese werden als gegeben vorausgesetzt und nur dort referenziert, wo L2 auf ihnen aufsetzt oder bestehende Defekte (siehe Review) die L2-Anforderungen begründen.
Multi-Consumer-Demultiplexing, Frame-Ownership-Vertrag, TX-Bestätigung, Adressierungs-Helfer, Threading-Modell je Protokollinstanz, Fehler-/Timeout-Infrastruktur
neu zu bauen – Gegenstand dieser SRS
L3
Transport-Ebene
ISO-TP (ISO 15765-2), J1939-TP (TP.BAM/TP.CM)
ISO-TP: unfertiger, funktional defekter Prototyp (CanKit.Transport.IsoTp); J1939-TP: nicht vorhanden
L4
Anwendungsprotokoll-Ebene
UDS (auf ISO-TP), CANopen, J1939 (Applikation)
nicht vorhanden
L2 ist die vom Auftraggeber geforderte zusätzliche „raw-CAN“-Schicht: Sie kapselt alles, was mehrere Protokoll-Stacks gemeinsam benötigen und was heute nicht (oder nicht korrekt) in L1 existiert.
Gehärteter, Multi-Consumer-fähiger Zugriff auf einen physischen CAN-Bus für mehrere gleichzeitig aktive Protokollinstanzen (z. B. UDS-Client + CANopen-Master auf demselben Kanal).
Vollständiges, spezifikationskonformes ISO-TP für Diagnose- und generische PDU-Übertragung.
J1939-Transportprotokoll für PGN-basierte Nutzfahrzeugkommunikation.
UDS-Client-Funktionalität für Diagnosewerkzeuge/Testautomatisierung.
CANopen-Basisdienste (SDO, PDO, NMT, Heartbeat, EMCY) für Automatisierungsanwendungen.
Die vier in Abschnitt 4.1 hergeleiteten L2-Architekturlücken (Frame-Ownership, Demultiplexing, Threading-Modell, TX-Confirm) müssen geschlossen sein, bevor L3/L4-Stacks produktiv gebaut werden; L3/L4-Anforderungen in dieser SRS setzen eine funktionsfähige L2 voraus.
A-2
Der bestehende ISO-TP-Prototyp (CanKit.Transport.IsoTp) wird als Ausgangsbasis für L3 wiederverwendet, nicht komplett neu geschrieben; die in Review §1.1 gelisteten Defekte werden als Korrekturaufwand in L3 eingeplant.
A-3
J1939-TP wird als eigenständiger Transport nach demselben SPI-Muster wie ISO-TP (IIsoTpRegister-Analogon) realisiert.
A-4
Vendor-SDK-Lizenzen (Peak PCANBasic, Kvaser CANlib, Vector XL-Driver) bleiben proprietär und werden nicht Teil dieser Spezifikation; nur die Integrationspunkte werden betrachtet.
A-5
HIL-Testinfrastruktur mit realer Hardware wird für Abnahmetests der L3/L4-Ebenen benötigt, ist aber nicht Gegenstand dieser SRS (siehe Abschnitt 7).
A-6
netstandard2.0 bleibt Ziel-TFM für Kernbibliothek und L2/L3, um .NET-Framework-Konsumenten (Windows-Altsysteme mit Kvaser/Vector/PCAN) zu unterstützen.
Die folgenden Anforderungen leiten sich direkt aus den vier im Review identifizierten Architekturlücken ab (Review, Gesamteinschätzung und §2.1–2.3), die vor dem Bau der Protokoll-Stacks (L3/L4) geschlossen werden müssen.
Hintergrund: Review §1.5 und §2.1 zeigen, dass CanFrame.Dispose() das ownMemory-Flag ignoriert und Frames ungeklärt zwischen Sender, Broadcast-Hub, Event-Handlern und Async-Pipes geteilt werden, was zu Use-after-free/Double-Dispose führt.
ID
Anforderung
Priorität
Verifikation
Quelle
FR-RAW-001
Das System MUSS einen verbindlichen, dokumentierten Frame-Ownership-Vertrag definieren, der für jede Frame-Übergabestelle (TX-Aufrufer→Adapter, Adapter-RX→Event/Pipe/Hub, Hub→Multi-Consumer) eindeutig festlegt, wer den Speicher besitzt und wann Dispose() aufgerufen werden darf.
Must
Dokumentationsreview + Architektur-Entscheidungsprotokoll; Vertrag ist in docs/architecture/arc42-CanKit.Pro.md referenzierbar.
Review §2.1, Empfehlung Pkt. 2
FR-RAW-002
Das System MUSS sicherstellen, dass CanFrame.Dispose() den zugrunde liegenden Speicher nur freigibt, wenn die Frame-Instanz laut Ownership-Vertrag Eigentümerin ist (Korrektur des in Review §1.5 beschriebenen Defekts).
Must
Unit-Test: Frame mit ownMemory=false erzeugen, Dispose() aufrufen, prüfen dass der zugrunde liegende IMemoryOwner<byte> nicht disposed wurde.
Review §1.5
FR-RAW-003
Das System MUSS dem Protokollentwickler die Möglichkeit bieten, empfangene Frames über eine reine Lesesicht (CanFrameView) zu konsumieren, ohne Ownership oder Dispose-Verantwortung zu übernehmen.
Must
Unit-Test: FrameObserved-Handler erhält CanFrameView; Aufruf von Dispose() ist auf dem View-Typ nicht möglich (Compile-Zeit-Prüfung).
Review §2.1; vorhandene CanFrameView in ICanBus.FrameObserved
FR-RAW-004
Das System MUSS beim Multi-Consumer-Broadcast (z. B. Virtual-Bus-Hub) jedem Consumer eine eigenständig lebensfähige Kopie oder eine referenzgezählte, erst nach Konsum aller Empfänger freigegebene Instanz liefern, sodass das Dispose eines Consumers die Daten anderer Consumer/des Senders nicht invalidiert.
Must
Integrationstest (Virtual-Loopback): 2 Consumer + Sender abonnieren denselben Frame; ein Consumer disposed sofort, die übrigen lesen danach unverändert weiter.
Review §2.1 (VirtualBusHub-Use-after-free)
FR-RAW-005
Das System SOLLTE für TX-Pfade dokumentieren und durchsetzen, dass der Aufrufer Eigentümer des übergebenen Frames bleibt, sofern der Adapter keine Kopie anfertigt, und dass Adapter interne Kopien anfertigen, bevor sie den Frame asynchron weiterverwenden (Scheduler-Queues, Echo-Matching).
Should
Codereview-Checkliste je Adapter/Transport; Regressionstest für ISO-TP-Scheduler-Echo-Matching (Review §2.1, Punkt „Scheduler (ISO-TP)“).
Hintergrund: Heute können mehrere Protokollinstanzen (z. B. ISO-TP + CANopen) nicht unabhängig voneinander gefilterte Sichten auf denselben ICanBus erhalten, ohne sich gegenseitig Frames wegzunehmen oder Callbacks zu blockieren.
ID
Anforderung
Priorität
Verifikation
Quelle
FR-RAW-010
Das System MUSS dem Protokollentwickler die Möglichkeit bieten, eine unabhängige, gefilterte Frame-Subscription (ID-Bereich, Maske oder Prädikat) auf einem gemeinsam genutzten ICanBus zu registrieren, ohne andere Subscriptions zu beeinträchtigen.
Must
Integrationstest: 2 Subscriptions mit disjunkten ID-Filtern auf demselben Virtual-Bus; jede erhält ausschließlich die zu ihr passenden Frames.
Das System MUSS sicherstellen, dass jede Subscription einen eigenen, unabhängigen Puffer/Pipe besitzt, sodass eine langsame oder blockierte Subscription den Empfang anderer Subscriptions oder des Basis-FrameObserved-Events nicht verzögert.
Must
Lasttest: eine Subscription verarbeitet künstlich langsam, zweite Subscription bleibt in Latenz/Durchsatz unbeeinträchtigt.
Abgeleitet aus Architekturlücke „Demultiplexing“
FR-RAW-012
Das System MUSS eine geordnete Ab-/Wiederanmeldung von Subscriptions (Dispose-Pattern) unterstützen, sodass beendete Protokollinstanzen (z. B. ISO-TP-Kanal geschlossen) keine Ressourcen (Threads, Puffer, Hub-Einträge) hinterlassen.
Must
Unit-Test: N Subscriptions erzeugen und disposen, danach Ressourcenzähler (Handles/Threads) unverändert gegenüber Ausgangszustand.
Review §2.4 (Virtual: VirtualBusHub._hubs Leak als Negativbeispiel)
FR-RAW-013
Das System SOLLTE eine Standard-Demultiplex-Strategie für den häufigen Fall „ein 11/29-Bit-CAN-ID-Bereich pro Protokollinstanz“ bereitstellen (Fast-Path ohne generisches Prädikat), um Overhead bei hoher Busfrequenz zu vermeiden.
Should
Performance-Test: Durchsatzvergleich ID-Bereichsfilter vs. generisches Prädikat bei ≥ 1000 Frames/s.
NFR-Performance, Abschnitt 5.1
FR-RAW-014
Das System KANN dem Protokollentwickler erlauben, Subscriptions zur Laufzeit umzukonfigurieren (Filterkriterien ändern), ohne die Subscription neu zu erzeugen.
Could
Unit-Test: Filterkriterium zur Laufzeit ändern, nachfolgende Frames folgen neuem Kriterium.
—
FR-RAW-015
Das System MUSS jedem Subscription-Element die vom Bus gemeldete Echo-Kennzeichnung und den vom Adapter erfassten Empfangszeitstempel mitgeben, und es MUSS Echo-Frames nur an Subscriptions ausliefern, die dies ausdrücklich angefordert haben (Standard: keine Echos).
Must
Unit-Test: Bus meldet Empfangs- und Echo-Frame; Standard-Subscription erhält nur den Empfangsframe, includeEcho: true erhält beide mit korrektem IsEcho; Zeitstempel erreicht den Subscriber unverändert.
4.1.3 Threading-/Aktor-Modell pro Protokollinstanz¶
Hintergrund: Review §1.1 Punkt 9/14 und §2.2/§2.3 zeigen unsynchronisierte Zugriffe auf geteilte Zustände (Scheduler-Listen, _tx-State, Timer-Kontexte) aus mehreren Threads sowie einen Busy-Loop-Scheduler ohne definiertes Nebenläufigkeitsmodell.
ID
Anforderung
Priorität
Verifikation
Quelle
FR-RAW-020
Das System MUSS für jede Protokollinstanz (z. B. einen ISO-TP-Kanal, einen CANopen-Node) ein definiertes, dokumentiertes Threading-Modell bereitstellen, das festlegt, auf welchem Thread/Kontext RX-Verarbeitung, TX-Scheduling und Timeout-Prüfung stattfinden.
Must
Architektur-Review + Nebenläufigkeitstest (stress test mit ThreadSanitizer-Äquivalent/Interlocked-Zähler) ohne Datenrennen-Berichte.
Review §1.1 Punkt 9, 14; Gesamteinschätzung „Threading-Modell“
FR-RAW-021
Das System MUSS interne, von mehreren Threads erreichbare Zustände einer Protokollinstanz (Kanal-Register, Zeitgeber-Queues, Zustandsautomaten) gegen nebenläufige Lese-/Schreibzugriffe absichern (z. B. Lock, Concurrent-Collection oder Single-Writer-Aktor).
Must
Unit-/Stresstest: paralleles AddChannel/RemoveChannel und laufende Verarbeitungsschleife ohne InvalidOperationException bei Enumeration.
Review §1.1 Punkt 14 (Router._channels, IsoTpScheduler._channels als List ohne Synchronisation)
FR-RAW-022
Das System MUSS einen ereignisgetriebenen (nicht Busy-Loop-basierten) Scheduling-Mechanismus für periodische/zeitgesteuerte Protokollaufgaben (z. B. STmin-Wartezeiten, Timeout-Prüfung) bereitstellen, der bei fehlender Arbeit blockiert statt CPU zu verbrauchen.
Must
Performance-Test: CPU-Auslastung eines inaktiven Kanals über 60 s < 1 % (Referenzwert, anzupassen an Zielplattform).
Review §1.1 Punkt 9 (100 %-CPU-Busy-Loop des IsoTpScheduler)
FR-RAW-023
Das System MUSS Hintergrundausnahmen einer Protokollinstanz konsistent über einen definierten Kanal (Event/Callback) an den Nutzer weiterreichen, statt sie im Aufrufer-Thread des auslösenden Adapters zu werfen oder als unbeobachtete Task-Exception zu verlieren.
Must
Unit-Test: künstlich ausgelöste Hintergrundausnahme wird über BackgroundExceptionOccurred-Äquivalent der Protokollinstanz beobachtet, RX-Loop des Adapters bleibt unbeeinträchtigt.
Review §1.1 Punkt 15
FR-RAW-024
Das System SOLLTE dem Protokollentwickler erlauben, den Ausführungskontext (z. B. dedizierter Thread vs. Thread-Pool vs. Nutzer-SynchronizationContext) je Protokollinstanz zu konfigurieren.
Should
Konfigurationstest: Instanz mit dediziertem Thread erzeugt, Callback wird nachweislich auf diesem Thread ausgeführt.
Hintergrund: Zustandsautomaten in L3/L4 (z. B. ISO-TP-Sendepfad, CANopen-SDO) benötigen eine verlässliche Aussage, wann ein Frame tatsächlich auf dem Bus gesendet wurde – nicht nur, dass er vom Treiber angenommen wurde. ICanBus.Transmit liefert nur die Anzahl akzeptierter Frames (ITransceiver.Transmit), keine Sende-Bestätigung; Echo-Unterstützung ist optional (CanFeature.Echo).
ID
Anforderung
Priorität
Verifikation
Quelle
FR-RAW-030
Das System MUSS dem Protokollentwickler eine einheitliche TX-Bestätigungs-Abstraktion bieten, die unabhängig davon funktioniert, ob der zugrunde liegende Adapter Hardware-Echo (CanFeature.Echo) unterstützt.
Must
Integrationstest gegen zwei Adapter-Konfigurationen (mit/ohne CanFeature.Echo), jeweils erfolgreicher TX-Confirm-Callback.
Review, Gesamteinschätzung „TX-Confirm-Abstraktion“; CanFeature.Echo in CanEnums.cs
FR-RAW-031
Das System MUSS bei Adaptern mit Echo-Unterstützung die tatsächliche Sendebestätigung (Echo-Frame) für das TX-Confirm nutzen und dabei Frames anhand geeigneter Kriterien (z. B. ID + Payload + Sequenznummer/Zeitfenster) korrekt dem ursprünglichen Sende-Aufruf zuordnen.
Must
Integrationstest (Virtual-Loopback mit Echo aktiviert): N gleichzeitig gesendete, inhaltsgleiche Frames werden korrekt einzeln bestätigt (kein Fehlmatching).
Review §1.1 Punkt 12 (QueuedDeadline.Enqueue crasht bei identischen Frames) als Negativbeispiel
FR-RAW-032
Das System MUSS bei Adaptern ohne Echo-Unterstützung eine dokumentierte Approximation des TX-Confirm bereitstellen (z. B. „angenommen vom Treiber“ als bestmögliche Bestätigung), die diesen Unterschied explizit an den Aufrufer kommuniziert (kein stillschweigendes Vortäuschen von Hardware-Bestätigung).
Must
Unit-Test: TX-Confirm-Ergebnis enthält Bestätigungsart (Echo vs. Treiber-Akzeptanz); Dokumentationsprüfung.
Abgeleitet aus Architekturlücke „TX-Confirm“
FR-RAW-033
Das System MUSS TX-Confirm-Fehlschläge (Timeout, Bus-Off, Ablehnung) als beobachtbares Ergebnis (z. B. fehlgeschlagenes Future/Task) an den Aufrufer melden, statt den Vorgang unbestimmt hängen zu lassen.
Must
Unit-Test: TX-Confirm-Timeout-Szenario liefert innerhalb der konfigurierten Frist ein Fehlerergebnis.
Review §1.1 Punkt 8, 10 (hängende Tasks bei ISO-TP als Negativbeispiel)
FR-RAW-034
Das System SOLLTE dem Protokollentwickler erlauben, das TX-Confirm-Timeout je Sendevorgang zu konfigurieren.
Should
Konfigurationstest: unterschiedliche Timeout-Werte führen zu proportional unterschiedlichem Fehlschlagzeitpunkt.
Das System MUSS dem Protokollentwickler Hilfsfunktionen zur Erzeugung, Validierung und Zerlegung von 11-Bit-(Standard-) und 29-Bit-(Extended-)CAN-IDs bereitstellen, einschließlich der für J1939 nötigen PGN/Priority/Source-Address-Aufteilung der 29-Bit-ID.
Must
Unit-Tests: Roundtrip Kodierung/Dekodierung für repräsentative Standard-, Extended- und J1939-PGN-IDs inkl. Grenzwerte (0, 0x7FF, 0x1FFFFFFF).
Das System SOLLTE dem Protokollentwickler Hilfsfunktionen zur Erkennung von ID-Kollisionen/Überlappungen zwischen registrierten Subscriptions anbieten (z. B. zur Fehlerdiagnose bei Fehlkonfiguration mehrerer Protokollinstanzen).
Should
Unit-Test: zwei überlappende Filterbereiche werden erkannt und gemeldet.
Das System MUSS eine wiederverwendbare Deadline-/Timeout-Primitive bereitstellen, die von L3/L4-Protokollen für zeitgebundene Zustandsübergänge (z. B. N_Bs, N_Cr, P2, SDO-Timeout) genutzt werden kann und deren Ablauf zuverlässig geprüft und gemeldet wird.
Must
Unit-Test: Deadline mit kurzer Frist löst nachweislich Timeout-Callback aus; Regressionstest gegen Review-Befund „Deadlines werden gepflegt, aber nie geprüft“.
Review §1.1 Punkt 10
FR-RAW-051
Das System MUSS Bus-Fehlerzustände (BusState: ErrWarning, ErrPassive, BusOff) den L3/L4-Protokollinstanzen so zur Verfügung stellen, dass diese aktive Übertragungen kontrolliert abbrechen oder pausieren können.
Must
Integrationstest: simulierter BusOff-Zustand führt bei aktivem L3-Sendevorgang zu definiertem Abbruch statt Hängenbleiben.
Abgeleitet aus ICanBus.BusState, ErrorCounters()
FR-RAW-052
Das System SOLLTE reservierte/ungültige Protokollwerte in eingehenden Frames (z. B. reservierte ISO-TP-STmin-Werte) gemäß Spezifikation robust behandeln, statt mit einer Ausnahme abzubrechen.
Should
Unit-Test analog Review §1.1 Punkt 6 (reservierte STmin-Werte 0x80–0xF0/0xFA–0xFF werden als 127 ms interpretiert statt Exception).
Ist-Zustand: unfertiger, funktional defekter Prototyp (CanKit.Transport.IsoTp); öffentlicher Einstieg wirft NotImplementedException (Review §1.1). Die folgenden Anforderungen umfassen sowohl die Fertigstellung/Fehlerbehebung als auch die vollständige Spezifikation des Zielverhaltens.
ID
Anforderung
Priorität
Verifikation
Quelle
FR-TP-001
Das System MUSS dem Protokollentwickler die Möglichkeit bieten, eine PDU beliebiger zulässiger Länge (Single Frame bis Multi-Frame, klassisches CAN und CAN-FD) über einen ISO-TP-Kanal zu senden (SendAsync) und den Abschluss der Übertragung asynchron zu erfahren.
Must
Integrationstest (Virtual-Loopback): SF- und Multi-Frame-Roundtrip für Nutzlasten 1–4095 Byte.
ISO 15765-2; Review §1.1 (Fehlerkatalog als Ausgangspunkt)
FR-TP-002
Das System MUSS eingehende ISO-TP-PDUs korrekt aus Single-, First- und Consecutive-Frames zusammensetzen und über DatagramReceived/GetFramesAsync bereitstellen.
Must
Integrationstest: Multi-Frame-Empfang mit korrekter Reassemblierung inkl. Sequenznummern-Prüfung.
ISO 15765-2 §6; Review §1.1 Punkt 7 (SN-Fehler als Negativbeispiel)
FR-TP-003
Das System MUSS Classic-CAN- und CAN-FD-Frames gemäß dem in den Kanaloptionen konfigurierten Modus korrekt erzeugen (Korrektur der in Review §1.1 Punkt 1 beschriebenen Invertierung canfd ? Classic : Fd).
Must
Unit-Test: IsoTpOptions mit CanFd=true erzeugt ausschließlich CanFrameType.CanFd-Frames für SF/FF/CF/FC.
Review §1.1 Punkt 1
FR-TP-004
Das System MUSS Flow-Control-Frames mit korrektem PCI-Typ (FC, nicht FF) und ohne Überschreiben von BS/STmin durch Padding erzeugen.
Must
Unit-Test: erzeugter FC-Frame hat PCI-Nibble 0x3, BS- und STmin-Byte entsprechen den übergebenen Werten.
Review §1.1 Punkt 2, 3
FR-TP-005
Das System MUSS First-Frame-Längenangaben > 255 Byte korrekt kodieren und dekodieren (Korrektur des High-Nibble-Bindungsfehlers).
Must
Unit-Test: FF-Länge-Roundtrip für Werte 256, 512, 4095.
Review §1.1 Punkt 4
FR-TP-006
Das System MUSS STmin-Werte gemäß ISO 15765-2 kodieren, einschließlich der häufigen Werte 0 ms und 1 ms, ohne Ausnahme zu werfen.
Must
Unit-Test: EncodeStmin(0), EncodeStmin(1000µs) liefern gültige Kodierung ohne Exception.
Review §1.1 Punkt 5
FR-TP-007
Das System MUSS reservierte STmin-Werte beim Dekodieren gemäß ISO 15765-2 als 0x7F (127 ms) behandeln und darf bei fehlerhaften/unerwarteten PCI-Längen keine unbehandelte IndexOutOfRangeException auslösen.
Must
Unit-Test: reservierte Werte 0x80–0xF0, 0xFA–0xFF liefern 127 ms; Fuzz-Test mit verkürzten PCI-Bytes löst keine unbehandelte Ausnahme aus.
Review §1.1 Punkt 6
FR-TP-008
Das System MUSS Consecutive Frames mit korrektem Nutzdaten-Offset (kein Datenverlust am FF/CF-Übergang) und korrekt beginnender Sequenznummer (SN=1 am ersten CF) senden.
Must
Integrationstest: Multi-Frame-Nachricht wird byteweise verlustfrei über Virtual-Loopback übertragen und verglichen.
Review §1.1 Punkt 7
FR-TP-009
Das System MUSS Multi-Frame-Sendevorgänge zuverlässig starten (First Frame wird gesendet und der Kanal wartet korrekt auf Flow Control), ohne dass der Sendevorgang unbeobachtet hängen bleibt.
Must
Integrationstest: SendAsync für Payload > SF-Grenze schließt innerhalb konfigurierter Zeit erfolgreich ab.
Review §1.1 Punkt 8
FR-TP-010
Das System MUSS alle ISO-TP-Zeitüberwachungen (N_As, N_Bs, N_Cr mind.) aktiv prüfen und bei Überschreitung den Sende-/Empfangsvorgang mit einem für den Aufrufer beobachtbaren Fehler abschließen.
Must
Integrationstest: künstlich verzögerte/ausbleibende Gegenstelle löst innerhalb der konfigurierten Deadline einen Fehler statt eines hängenden Tasks aus.
Review §1.1 Punkt 10
FR-TP-011
Das System MUSS Flow-Control „Wait“ (FS=WT) nur bis zu einer konfigurierbaren Obergrenze (WFTmax) akzeptieren und danach den Vorgang abbrechen.
Must
Unit-Test: Gegenstelle sendet WT häufiger als WFTmax → Abbruch mit Fehler.
ISO 15765-2 §6.3 (WFTmax); Review §1.1 Punkt 10
FR-TP-012
Das System MUSS auf Overflow-Flow-Control (FS=OVFLW) den laufenden Sendevorgang mit einem beobachtbaren Fehlerergebnis abschließen statt ihn nur intern als „Failed“ zu markieren.
Must
Unit-Test: FS=OVFLW-Antwort führt zu fehlgeschlagenem SendAsync-Task innerhalb definierter Zeit.
Review §1.1 Punkt 10
FR-TP-013
Das System MUSS auf netstandard2.0-Zielplattformen denselben korrekten TX-Warteschlangen-Ablauf wie auf net8.0 liefern (Korrektur der invertierten TryPeek-Polyfill-Logik).
Must
Unit-Test explizit gegen netstandard2.0-Build: TX-Queue liefert bei leerer Queue kein Element ohne Ausnahme, bei gefüllter Queue das erwartete Element.
Review §1.1 Punkt 11
FR-TP-014
Das System MUSS mehrere gleichzeitig „in flight“ befindliche Frames mit identischem Inhalt (z. B. gepaddete Consecutive Frames) im Deadline-/Confirm-Tracking unterstützen, ohne abzustürzen.
Must
Unit-Test: zwei inhaltsgleiche Frames gleichzeitig in Bearbeitung, keine Ausnahme, korrekte getrennte Zeitüberwachung.
Review §1.1 Punkt 12; siehe auch FR-RAW-031
FR-TP-015
Das System MUSS den ISO-TP-internen Frame-Buffer über den in FR-RAW-002 definierten Ownership-Vertrag beziehen (kein direktes ArrayPool.Rent ohne Rückgabe, keine Frames > 8 Byte für Classic-CAN).
Must
Unit-Test: SF-Erzeugung für Classic-CAN erzeugt gültigen ≤8-Byte-Frame ohne ArgumentOutOfRangeException; Speicher-Leak-Test über N Sendevorgänge.
Review §1.1 Punkt 13
FR-TP-016
Das System MUSS das in FR-RAW-020..023 definierte Threading-Modell für den ISO-TP-Scheduler umsetzen: ereignisgetrieben statt Busy-Loop, synchronisierter Zugriff auf Kanalregister, konsistente Fehlerweiterleitung.
Must
Wie FR-RAW-022/023, angewandt auf IsoTpScheduler.
Review §1.1 Punkt 9, 14, 15
FR-TP-017
Das System MUSS die TX-Bestätigung für ISO-TP-Sendevorgänge über die in FR-RAW-030..033 definierte Abstraktion realisieren (kein direktes SetResult/SetException in Race-Situationen mit Cancellation).
Must
Unit-Test: gleichzeitige Cancellation und TX-Fehlschlag führen zu genau einem konsistenten Ergebnis, keine InvalidOperationException.
Review §1.1 Punkt 14
FR-TP-018
Das System SOLLTE dem Protokollentwickler erlauben, mehrere ISO-TP-Kanäle mit unterschiedlichen Adresspaaren gleichzeitig über denselben physischen Bus zu betreiben (Nutzung des L2-Demultiplexing gemäß FR-RAW-010ff.).
Should
Integrationstest: zwei ISO-TP-Kanäle mit unterschiedlichen CAN-IDs auf demselben Virtual-Bus arbeiten unabhängig und korrekt.
Abgeleitet aus L2-Anforderungen
FR-TP-019
Das System KANN Funktionale Adressierung (Functional Addressing, 1:n-Anfragen gemäß ISO 15765-2/ISO 14229) unterstützen.
Could
Integrationstest: funktionale Anfrage wird von mehreren simulierten ECUs beantwortet.
ISO 15765-2
FR-TP-020
Das System MUSS das ISO-TP-Paket in seiner Abhängigkeitsliste keine unnötigen Vendor-SDK-Referenzen (z. B. Peak.PCANBasic.NET) enthalten.
Must
Build-/Paketprüfung: CanKit.Transport.IsoTp.csproj referenziert keine Adapter-spezifischen Vendor-Pakete.
Das System MUSS dem Protokollentwickler die Möglichkeit bieten, PDUs bis 1785 Byte per Broadcast Announce Message (TP.BAM) an alle Netzteilnehmer zu senden.
Must
Integrationstest (Virtual-Loopback): BAM-Übertragung, mehrere Empfänger reassemblieren identisch.
SAE J1939-21
FR-TP-031
Das System MUSS dem Protokollentwickler die Möglichkeit bieten, PDUs per verbindungsorientiertem Transportprotokoll (TP.CM: RTS/CTS/EndOfMsgAck) an eine bestimmte Zieladresse zu senden, inkl. Segmentgrößen-Aushandlung über CTS.
Das System MUSS TP.CM-Zeitüberwachungen (T1–T4, Tr, Th) prüfen und Verbindungsabbrüche (Connection Abort) bei Überschreitung auslösen.
Must
Integrationstest: ausbleibende Gegenstelle löst Abort innerhalb der Spezifikationsfristen aus.
SAE J1939-21
FR-TP-033
Das System MUSS empfangsseitig sowohl TP.BAM- als auch TP.CM-Nachrichten korrekt anhand PGN 0xEC00/0xEB00 erkennen und den zugehörigen Reassemblierungs-Zustandsautomaten zuordnen.
Must
Unit-Test: gemischter Frame-Stream aus BAM- und CM-Sessions wird korrekt getrennt reassembliert.
SAE J1939-21
FR-TP-034
Das System MUSS das J1939-TP analog zu ISO-TP über das L2-Threading-Modell (FR-RAW-020ff.) und den Ownership-Vertrag (FR-RAW-001f.) implementieren.
Must
Wie FR-TP-016/017, angewandt auf J1939-TP.
Konsistenzanforderung
FR-TP-035
Das System SOLLTE mehrere gleichzeitige TP.CM-Sessions mit unterschiedlichen Peer-Adressen unterstützen.
Should
Integrationstest: zwei parallele TP.CM-Sessions zu unterschiedlichen Zieladressen ohne gegenseitige Störung.
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, eine Diagnose-Session zu wechseln (DiagnosticSessionControl, Service 0x10) und die aktive Session zu verfolgen.
Must
Integrationstest gegen simulierte ECU: Sessionwechsel Default→Extended, Bestätigung ausgewertet.
ISO 14229-1 §9.2
FR-UDS-002
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, einen Data Identifier zu lesen (ReadDataByIdentifier, Service 0x22).
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, eine Routine zu steuern (RoutineControl – Start/Stop/RequestResults, Service 0x31).
Must
Integrationstest: alle drei Sub-Funktionen gegen simulierte ECU.
ISO 14229-1 §9.10
FR-UDS-005
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, einen ECU-Reset auszulösen (Service 0x11) und die Reset-Bestätigung zu verarbeiten.
Must
Integrationstest: Reset-Anfrage + positive Response vor Verbindungsabbruch der simulierten ECU.
ISO 14229-1 §9.1
FR-UDS-006
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, Security Access (Service 0x27) durchzuführen (Seed-Anfrage, Key-Übermittlung), wobei die Schlüsselberechnung außerhalb von CanKit liegt (Callback/Delegat).
Must
Integrationstest: Seed/Key-Austausch mit injiziertem Test-Algorithmus.
ISO 14229-1 §9.4
FR-UDS-007
Das System MUSS dem Diagnose-Tester die Möglichkeit bieten, Tester Present (Service 0x3E) periodisch zu senden, um eine Session am Leben zu erhalten.
Must
Integrationstest: periodische 0x3E-Sendung über konfigurierbares Intervall, Session bleibt aktiv.
ISO 14229-1 §9.12
FR-UDS-008
Das System MUSS P2- und P2*-Server-Timing (Default- und erweiterte Antwortzeit) überwachen und dem Aufrufer als Timeout melden, wenn die ECU nicht innerhalb der Frist antwortet.
Must
Integrationstest: verzögerte simulierte ECU-Antwort knapp über P2 löst Timeout aus, knapp darunter nicht.
ISO 14229-1 §7.3 (P2/P2*)
FR-UDS-009
Das System MUSS Response Pending (NRC 0x78) korrekt behandeln, indem es die P2*-Frist neu startet und auf die endgültige Antwort wartet, statt vorzeitig zu terminieren.
Must
Integrationstest: simulierte ECU sendet 1..n mal 0x78, gefolgt von finaler Antwort; Aufrufer erhält die finale Antwort ohne Timeout.
ISO 14229-1 §7.3.3
FR-UDS-010
Das System MUSS Negative Response Codes (NRC) strukturiert an den Aufrufer weiterreichen (Service, angeforderter Service, NRC-Wert), statt sie als generische Ausnahme ohne Kontext zu melden.
Must
Unit-Test: simulierte NRC-Antwort (z. B. 0x31 „Request Out Of Range“) wird mit korrektem Kontext im Fehlerergebnis abgebildet.
ISO 14229-1 §8.7
FR-UDS-011
Das System SOLLTE Multi-DID-Lesevorgänge (Service 0x22 mit mehreren DIDs in einer Anfrage) unterstützen.
Should
Integrationstest: Anfrage mit 3 DIDs, korrekte Zuordnung der Antwortdaten.
ISO 14229-1 §9.3
FR-UDS-012
Das System KANN Upload/Download-Services (RequestDownload/TransferData/RequestTransferExit, Services 0x34/0x36/0x37) für Flash-/Datenübertragung unterstützen.
Could
Integrationstest: vollständiger Download-Zyklus gegen simulierte ECU.
Das System MUSS dem Applikationsentwickler die Möglichkeit bieten, ein lokales Objektverzeichnis (OD) mit Index/Subindex-Einträgen zu definieren und zur Laufzeit zu lesen/schreiben.
Das System MUSS PDO-Mapping (statisch/dynamisch) für TPDO (Transmit) und RPDO (Receive) unterstützen, inklusive Zuordnung von OD-Einträgen zu PDO-Nutzdaten-Offsets.
Must
Unit-Test: PDO-Mapping-Konfiguration erzeugt korrekten Frame-Payload aus gemappten OD-Werten und umgekehrt.
CiA 301 §7.3
FR-CO-006
Das System MUSS Event- und zeitgesteuertes TPDO-Senden (Change-of-State, Timer) sowie SYNC-getriggertes PDO-Senden/-Empfangen unterstützen.
Must
Integrationstest: TPDO wird bei OD-Wertänderung bzw. bei SYNC-Empfang korrekt gesendet.
CiA 301 §7.3, §7.5
FR-CO-007
Das System MUSS NMT-Zustandswechsel (Pre-Operational, Operational, Stopped, Reset) sowohl als NMT-Master (Kommandos senden) als auch als NMT-Node (Kommandos empfangen und Zustand wechseln) unterstützen.
Must
Integrationstest: alle vier NMT-Kommandos gegen simulierten Node/Master mit korrektem Zustandsübergang.
CiA 301 §7.2.8.3
FR-CO-008
Das System MUSS Heartbeat-Produktion (periodisches Senden des eigenen Zustands) und Heartbeat-Konsumption (Timeout-Erkennung bei ausbleibendem Heartbeat eines überwachten Node) unterstützen.
Must
Integrationstest: ausbleibender Heartbeat löst innerhalb der konfigurierten Frist ein Timeout-Ereignis aus.
CiA 301 §7.2.8.3.4
FR-CO-009
Das System KANN Node-Guarding (Legacy-Alternative zu Heartbeat) unterstützen.
Das System MUSS SYNC-Objekte senden (als Sync-Producer) und empfangen (als Sync-Consumer) können.
Must
Integrationstest: SYNC-Frame löst konfigurierte SYNC-getriggerte PDOs aus.
CiA 301 §7.2.6
FR-CO-011
Das System MUSS Emergency-Objekte (EMCY) beim Auftreten interner Fehlerzustände senden und empfangene EMCY-Objekte strukturiert (Error Code, Error Register, Herstellerdaten) an den Applikationsentwickler weiterreichen.
Must
Unit-Test: EMCY-Frame wird korrekt kodiert/dekodiert inkl. aller Felder.
CiA 301 §7.2.7
FR-CO-012
Das System SOLLTE das L2-Multi-Consumer-Demultiplexing (FR-RAW-010ff.) nutzen, um NMT-, SDO-, PDO- und SYNC-Verkehr eines Node parallel und unabhängig zu verarbeiten.
Should
Integrationstest: gleichzeitiger SDO- und PDO-Verkehr auf demselben Node ohne gegenseitige Verzögerung.
Ist-Zustand: nicht vorhanden, Neubau; setzt FR-TP-030ff. voraus.
ID
Anforderung
Priorität
Verifikation
Quelle
FR-J1939-001
Das System MUSS dem Applikationsentwickler die Möglichkeit bieten, Nachrichten anhand PGN zu senden/empfangen und dabei Priority, PDU-Format (PF), PDU-Specific (PS) und Source Address gemäß J1939-21 korrekt in die 29-Bit-ID zu kodieren/dekodieren.
Must
Unit-Test: PGN-Roundtrip für PDU1- und PDU2-Format-Nachrichten.
SAE J1939-21
FR-J1939-002
Das System MUSS dem Applikationsentwickler die Möglichkeit bieten, einzelne SPN-Werte — vorzeichenlos oder im Zweierkomplement — aus einem empfangenen PGN-Payload gemäß konfigurierbarer Skalierung/Offset zu extrahieren. Die Indikatorbereiche nach SAE J1939-71 §5.1.1 (not available, error, reserviert, parameterspezifisch) MÜSSEN dabei als solche gemeldet werden und DÜRFEN NICHT als physikalischer Messwert ausgegeben werden.
Must
Unit-Test: SPN-Extraktion mit bekannten Skalierungsfaktoren liefert erwartete physikalische Werte; Known-Answer-Tests je Indikatorbereich und an dessen Grenzen für 1-, 2- und 4-Byte-Felder sowie für Sub-Byte- und vorzeichenbehaftete SPN.
SAE J1939-71 §5.1.1, §5.1.3
FR-J1939-003
Das System MUSS das Address-Claiming-Verfahren (Senden/Empfangen des Address-Claim-Frames PGN 0xEE00, Konfliktauflösung nach NAME-Priorität) unterstützen.
Must
Integrationstest: zwei simulierte Nodes mit kollidierender Adresse, korrekte Konfliktauflösung nach NAME.
SAE J1939-81
FR-J1939-004
Das System MUSS Cannot-Claim-Address-Verhalten (kein verfügbarer Adressplatz) gemäß Spezifikation signalisieren.
Must
Integrationstest: alle Adressen belegt, Node meldet Cannot-Claim korrekt.
SAE J1939-81
FR-J1939-005
Das System MUSS Request-PGN (PGN 0xEA00) senden und empfangen können, um gezielt eine PGN von einem oder allen Netzteilnehmern anzufordern.
Must
Integrationstest: Request-PGN löst erwartete Antwort-PGN aus.
SAE J1939-21
FR-J1939-006
Das System MUSS für PGN-Nachrichten > 8 Byte automatisch das J1939-TP (FR-TP-030ff.) verwenden, für ≤8 Byte den direkten Single-Frame-Pfad.
Must
Integrationstest: PGN mit 20-Byte-Payload nutzt TP.BAM/TP.CM, PGN mit 6-Byte-Payload nutzt Single Frame.
SAE J1939-21
FR-J1939-007
Das System SOLLTE periodisches Senden von PGNs mit spezifikationsgemäßer Standardrate unterstützen (Nutzung von IPeriodicTx/L2-Scheduling).
Should
Integrationstest: konfigurierte PGN wird mit korrekter Periodenrate gesendet.
Periodisches Senden (L1 IPeriodicTx/L2-Scheduling) MUSS auf Windows und Linux einen Jitter innerhalb eines dokumentierten Toleranzbandes einhalten (Zielwert projektspezifisch festzulegen, z. B. < 1 ms bei Software-Timing).
Must
Performance-Test: Zeitstempelmessung von N periodischen Sendungen, Jitter-Histogramm.
NFR-Vorgabe „Echtzeit/Jitter“
NFR-002
Das System MUSS auf macOS keinen Busy-Loop im Software-Timing-Pfad ausführen; bei fehlender clock_nanosleep-Verfügbarkeit MUSS auf Thread.Sleep-Fallback umgeschaltet werden (Korrektur Review §2.3).
Must
Unit-/Integrationstest auf macOS-Runner: CPU-Auslastung eines aktiven periodischen Senders bleibt in normalem Bereich, kein Sende-Sturm.
ISO-TP-STmin-Einhaltung MUSS innerhalb einer dokumentierten Genauigkeit (z. B. ±1 ms oder Adapter-Auflösung) eingehalten werden.
Must
Integrationstest: gemessene Inter-Frame-Zeit von Consecutive Frames vs. konfiguriertes STmin.
ISO 15765-2
NFR-004
Das System MUSS auf allen deklarierten Ziel-Frameworks (netstandard2.0, net8.0, net8.0-windows) funktional äquivalentes Verhalten für L2/L3-Kernlogik liefern (keine plattformspezifischen Logikfehler wie die invertierte TryPeek-Polyfill).
Must
CI-Testmatrix über alle drei TFMs mit identischen Testergebnissen für L2/L3-Kernszenarien.
Review §1.1 Punkt 11; CON-001
NFR-005
Vendor-adapterabhängige L0/L1-Funktionalität (Kvaser, PCAN, Vector, ControlCAN) MUSS auf ihre jeweils unterstützten Plattformen (i. d. R. Windows) beschränkt bleiben und darf auf nicht unterstützten Plattformen einen klaren Fehler statt eines unspezifizierten Crashs liefern.
Must
Buildmatrix-/Smoke-Test je Plattform.
CON-002
NFR-006
Fehlerzustände (Bus-Off, Timeout, Verbindungsabbruch) MÜSSEN in L2/L3/L4 konsistent über strukturierte Ausnahmen/Ergebnistypen kommuniziert werden, nicht durch stillschweigend verlorene oder auf falschem Thread geworfene Exceptions (Korrektur Review §1.1 Punkt 15, §2.2).
Must
Unit-Tests je Fehlerpfad; Regressionstest gegen „Exception im falschen Kontext“-Befunde.
Review §1.1 Punkt 15; §2.2
NFR-007
Ressourcenkritische Pfade (Frame-Erzeugung/-Versand in L2/L3 bei hoher Bus-Last) SOLLTEN Allokationen minimieren (Pooling gemäß Ownership-Vertrag, kein ArrayPool.Rent ohne Rückgabe).
Should
Benchmark: Allokationsmessung (Bytes/Frame) für ISO-TP-SF/CF-Pfad vor/nach Umsetzung.
Review §1.1 Punkt 13
NFR-008
Das System MUSS Thread-Safety für alle von mehreren Protokollinstanzen gleichzeitig genutzten L2-Komponenten (Demultiplex-Hub, Registry, Scheduler) gewährleisten.
Must
Stresstest mit parallelen Registrierungen/Abmeldungen und gleichzeitigem RX/TX-Verkehr ohne Datenrennen.
Review §1.1 Punkt 14; §2.5 (CanRegistry ohne Lock)
NFR-009
Alle L2/L3/L4-Komponenten MÜSSEN gegen den bestehenden Virtual-Adapter (Loopback, ohne reale Hardware) testbar sein, um CI-taugliche Regressionstests zu ermöglichen.
Must
CI-Lauf: vollständige L2/L3/L4-Testsuite läuft ohne Hardware-Abhängigkeit gegen CanKit.Adapter.Virtual.
Neue Protokoll-Ebenen (L3/L4) MÜSSEN dem bestehenden SPI-Erweiterbarkeitsmuster folgen (eigenständiges Paket, Registrierung über [CanRegistryEntry]/ICanRegistryEntry-Analogon), um Wartbarkeit und lose Kopplung zum Kern zu sichern.
Must
Architekturreview: neues Transport-/Protokollpaket registriert sich ausschließlich über SPI, ohne Änderungen an CanKit.Core.
Öffentliche APIs neuer Ebenen (L2/L3/L4) SOLLTEN von Anfang an konsistente Namensgebung verwenden (keine Typos wie Excpetions, ReadTImeOutMs, ExceptionOccured aus dem bestehenden Code), da spätere Korrekturen Breaking Changes wären.
Should
API-Review/Linting-Checkliste vor 1.0-Release.
Review §3, Empfehlung Pkt. 8
NFR-012
Zeitstempel in neu geschaffenen L2/L3/L4-Datenstrukturen MÜSSEN einheitlich UTC verwenden (Korrektur der Inkonsistenz DateTime.Now vs. DateTime.UtcNow in L1).
Should
Codereview-Checkliste; Unit-Test auf DateTimeKind.Utc.
Alle L2/L3-Pakete MÜSSEN mindestens netstandard2.0, net8.0 und net8.0-windows als Ziel-Frameworks unterstützen (gemäß src/Directory.Build.props).
technisch
src/Directory.Build.props
CON-002
Vendor-Adapter-Integrationen (PCAN, Kvaser, Vector, ControlCAN) basieren auf P/Invoke gegen proprietäre native SDKs/DLLs; L2/L3-Komponenten dürfen diese Abhängigkeiten nicht direkt referenzieren, sondern ausschließlich über ICanBus/ITransceiver-Abstraktionen nutzen.
technisch
Review §1.1 Punkt 16 (Negativbeispiel: ISO-TP referenziert Peak.PCANBasic.NET grundlos)
CON-003
Lizenzbedingungen der Vendor-SDKs (Peak PCANBasic, Kvaser CANlib, Vector XL-Driver) sind proprietär; Distribution/Verwendung dieser SDKs unterliegt Drittanbieter-Lizenzen, die außerhalb der Kontrolle dieses Projekts liegen.
Neue Pakete (L3/L4) MÜSSEN, solange sie funktional unvollständig sind, klar als experimentell gekennzeichnet oder von der Release-Pipeline ausgeschlossen werden (IsPackable=false), analog der Review-Empfehlung für den aktuellen ISO-TP-Stand.
organisatorisch
Review §1.1, Empfehlung Pkt. 1
CON-005
Das Projekt verwendet MIT-Lizenzierung (PackageLicenseExpression in Directory.Build.props); neue L3/L4-Pakete MÜSSEN dieselbe Lizenz führen, sofern keine abweichende vertragliche Regelung entgegensteht.
rechtlich/organisatorisch
src/Directory.Build.props
CON-006
CI-Workflows testen aktuell projektweise über .slnf-Filterdateien (z. B. CanKitAdapters.slnf, CanKitTransports.slnf); neue L3/L4-Pakete MÜSSEN in eine passende .slnf-Datei mit eigenem CI-Workflow aufgenommen werden.
organisatorisch
Review §4 („ISO-TP-Projekt hat keinen eigenen Workflow“)
CON-007
Der Standard-Git-Branch ist master; Release-/Paket-Pipelines MÜSSEN konsistent auf diesen Branch referenzieren.
Simulierte Gegenstellen (Test-ECU/-Node) auf Basis des Virtual-Adapters.
Fake-Native-Test
Adapterverhalten (L0/L1) ohne reale Vendor-Hardware über *.Fake.cs-Schicht (-c Fake-Konfiguration).
L1 (bereits etabliert), indirekt L2/L3, wo adapterspezifisches Verhalten (Echo, Timeout) relevant ist.
Bestehende Fake-Konfiguration je Adapter.
Stress-/Nebenläufigkeitstest
Aufdeckung von Datenrennen, Deadlocks, Leaks unter paralleler Last (mehrere Protokollinstanzen, häufige Subscribe/Unsubscribe-Zyklen).
L2 (Threading-Modell, Registry), L3 (Scheduler)
Wiederholte Ausführung (N-fach), ggf. mit Race-Detection-Tools.
Performance-/Timing-Test
Messung von Jitter, Durchsatz, STmin-Genauigkeit, CPU-Auslastung im Leerlauf.
NFR-001..003, NFR-007
Referenzplattformen (Windows, Linux; macOS für NFR-002).
HIL-Test (Hardware-in-the-Loop)
Validierung gegen reale ECUs/Bus-Hardware für ausgewählte kritische Szenarien (z. B. reale UDS-Diagnosesitzung, reales CANopen-Gerät).
Stichprobenhaft für L4 (UDS, CANopen, J1939) vor Produktivfreigabe.
Reale Testhardware, außerhalb des CI-Standardlaufs; siehe Annahme A-5.
Architektur-/Codereview
Prüfung nicht automatisiert testbarer Anforderungen (Dokumentation, SPI-Konformität, Namenskonventionen).
FR-RAW-001, NFR-010, NFR-011
Checkliste, Teil des PR-Reviewprozesses.
Grundprinzip: Jede Must-Anforderung MUSS mindestens durch Unit- oder Virtual-Loopback-Integrationstest abgedeckt sein, bevor die jeweilige Ebene als „fertig“ gilt. HIL-Tests ergänzen für produktionskritische L4-Szenarien, sind aber wegen Hardwareabhängigkeit nicht Teil des Standard-CI-Gates.
Verweise auf Architektur-Bausteine nutzen die in Abschnitt 2.1 definierten Schichtnamen L0–L4 und sind konsistent mit den in docs/architecture/arc42-CanKit.Pro.md (parallel in Erstellung) zu erwartenden Bausteinnamen. Wo das Architekturdokument zum Zeitpunkt dieser SRS noch nicht existiert, wird der erwartete Baustein benannt (kursiv gekennzeichnet als geplant).
Anforderung(en)
Architektur-Baustein (L0–L4)
Verifikation
FR-RAW-001..005
L2 – Frame-Ownership-Vertrag (geplant), aufbauend auf L1 CanFrame/CanFrameView (src/core/CanKit.Abstractions/API/Can/Definitions/CanFrame.cs)
Unit-Test, Virtual-Loopback-Integrationstest
FR-RAW-010..015
L2 – Demultiplex-Hub/Subscription-Manager (umgesetzt in CanKit.Pro.RawCan), aufbauend auf L1 ICanBus.FrameObserved (src/core/CanKit.Abstractions/API/Can/ICanBus.cs)
Virtual-Loopback-Integrationstest, Lasttest
FR-RAW-020..024
L2 – Protokollinstanz-Aktor/Scheduler (umgesetzt als eigenständiges CanKit.Pro.Actor, IProtocolActor/ProtocolActor); Referenzimplementierung noch nicht umgestellt in L3 IsoTpScheduler (src/transports/CanKit.Transport.IsoTp/IsoTpScheduler.cs, funktional defekt, s. Review §1.1)
Stress-/Nebenläufigkeitstest
FR-RAW-030..034
L2 – TX-Confirm-Abstraktion (umgesetzt in CanKit.Pro.RawCan), aufbauend auf L1 CanFeature.Echo, ITransceiver.Transmit
Virtual-Loopback-Integrationstest (mit/ohne Echo)
FR-RAW-040..041
L2 – Adressierungs-Helfer (umgesetzt als eigenständiges CanKit.Pro.Addressing: CanIdRange, J1939Id/J1939Fields; FR-RAW-041 als CanIdFilter.Overlaps/ICanBusService.FindOverlappingFilterSubscriptions() in CanKit.Pro.RawCan, Ergebnis je Treffer als benannter FilterOverlap mit beiden Subscriptions und dem geteilten ID-Bereich)
Unit-Test
FR-RAW-050..052
L2 – Fehler-/Timeout-Infrastruktur (FR-RAW-050/051 umgesetzt als eigenständiges CanKit.Pro.Reliability: IDeadlineScheduler/DeadlineScheduler/Deadline als aktorgetriebene Deadline-Primitive, deren Ablauf über IProtocolActor.Schedule tatsächlich geprüft und gemeldet wird (FR-RAW-050); BusStateMonitor/BusStateChangedEventArgs/BusStateExtensions für gepushte ICanBus.BusState-Übergänge (FR-RAW-051), aufbauend auf CanKit.Pro.Actor und L1 ICanBus.BusState). FR-RAW-052 (reservierte/ungültige Protokollwerte) bleibt zurückgestellt und dem künftigen ISO-TP-Codec-Fix FR-TP-007 zugeordnet (Review §1.1 Punkt 6), da protokollspezifisch statt generische L2-Primitive.
Konkrete Zielwerte für Jitter/Durchsatz (NFR-001) sind projektspezifisch festzulegen (aktuell als Platzhalter markiert) – abhängig von Zielanwendungen (Diagnose vs. Steuerungs-Echtzeit).
J1939-TP- und CANopen-Pakete existieren im Repository noch nicht; Anforderungen in Abschnitt 4.2.2/4.3.2/4.3.3 sind Neubau-Spezifikationen ohne Ist-Code-Referenz.
Die Traceability-Matrix referenziert docs/architecture/arc42-CanKit.Pro.md, das zum Zeitpunkt dieser SRS noch nicht vorliegt; Bausteinnamen sind als geplant markiert und beim Erscheinen des Architekturdokuments gegenzuprüfen.