FlexRay Transport Layer (FrTp)

FrTp überträgt große Nachrichten zwischen PduR und FrIf nach ISO 10681-2 ([SWS_FrTp_01005]). Es segmentiert und reassembliert sie, steuert den Fluss und verteilt die Bandbreite über gemeinsam genutzte Tx-PDU-Pools. FrTp_Transmit nimmt einen Sendeauftrag nur an; die eigentliche Arbeit erledigt die zyklische FrTp_MainFunction, die mindestens einmal je FlexRay-Zyklus laufen muss ([SWS_FrTp_01152]). Unterstützt werden quittierte und unquittierte Übertragungen sowie Nachrichten unbekannter Länge. Bei Protokollfehlern oder unzulässiger Segmentierung bricht FrTp ab und meldet E_NOT_OK an den PduR.

mehr ›

FrTp ist der Transportlayer für FlexRay nach ISO 10681-2. Wo die Spezifikation nichts Eigenes festlegt, folgt das Modul dieser Norm ([SWS_FrTp_01005]). Es zerlegt große N-SDUs des PduR in N-PDUs, gibt sie mit FrIf_Transmit an FrIf weiter und setzt empfangene Rahmen wieder zusammen ([SWS_FrTp_01050], FrTp SWS S. 19). Verarbeitet wird nur im Zustand FRTP_ON, also zwischen FrTp_Init und FrTp_Shutdown ([SWS_FrTp_01032], [SWS_FrTp_01036]). FrTp_MainFunction muss mindestens einmal je FlexRay-Zyklus laufen ([SWS_FrTp_01152]).

Kontextdiagramm: FrTp zwischen PduR und FrIf, gesteuert von EcuM und BSW-Scheduler. Quellen: [SWS_FrTp_00577], FrTp SWS S. 21

Senden beginnt immer mit FrTp_Transmit. Der Aufruf belegt nur einen Kanal und setzt TX_SDU_AVAILABLE ([SWS_FrTp_00136], [SWS_FrTp_01039]). Die MainFunction erledigt den Rest: Sie holt die Daten per PduR_FrTpCopyTxData, belegt den ersten freien Pool-PDU und entscheidet über die Segmentierung ([SWS_FrTp_01045], [SWS_FrTp_01048]). Im Modus „Decoupled Buffer Access“ holt FrIf die Daten später per FrTp_TriggerTransmit ab ([SWS_FrTp_01060]). PduR_FrTpTxConfirmation folgt nach jedem angenommenen Auftrag ([SWS_FrTp_01058]).

Sequenzdiagramm: Annahme des Auftrags, Abarbeitung in der MainFunction, Bestätigung je N-PDU und am Ende an den PduR. Quellen: FrTp SWS S. 44, [SWS_FrTp_01042]

Beim Empfang prüft FrTp RxPduId und Adressen gegen die Verbindungskonfiguration ([SWS_FrTp_01069], [SWS_FrTp_01071]). Bei einer neuen Verbindung ruft es PduR_FrTpStartOfReception auf, kopiert die Fragmente nach oben und sendet bei Bedarf FlowControl ([SWS_FrTp_01078], [SWS_FrTp_01080]). Unterstützt werden sechs Varianten: unsegmentiert oder segmentiert, mit oder ohne Quittung, mit bekannter oder unbekannter Länge ([SWS_FrTp_01007]–[SWS_FrTp_01012]). Mehrere Verbindungen teilen sich Tx-PDU-Pools und werden abwechselnd bedient ([SWS_FrTp_01020], [SWS_FrTp_01096]).

Im Fehlerfall bricht FrTp in drei Situationen ab und meldet E_NOT_OK an den PduR: bei ungültigem oder abbrechendem Flow Status und bei Segmentierungsbedarf auf 1:n-Verbindungen ([SWS_FrTp_01198], [SWS_FrTp_01208]). Laufzeitfehler sind FRTP_E_SEG_ERROR und FRTP_E_NO_CHANNEL. Timer und Zähler wie das FC.WAIT-Limit begrenzen Wartezeiten ([SWS_FrTp_01100], [SWS_FrTp_01114]). Laufende Übertragungen lassen sich mit FrTp_CancelTransmit und FrTp_CancelReceive abbrechen ([SWS_FrTp_01116], [SWS_FrTp_01181]).

mehr ›

Rolle im FlexRay-Stack und Modulzustand

FrTp ist der FlexRay-Transportlayer nach ISO 10681-2. Wo die Spezifikation nichts Eigenes festlegt, folgt das Modul dieser Norm und unterstützt deren N-PDU-Formate ([SWS_FrTp_01005], [SWS_FrTp_01006]). Nach oben bedient FrTp den PduR. Der PduR startet Übertragungen mit FrTp_Transmit, bricht sie ab oder ändert Parameter. FrTp liefert über PduR_FrTpStartOfReception, PduR_FrTpCopyRxData, PduR_FrTpCopyTxData, PduR_FrTpRxIndication und PduR_FrTpTxConfirmation Daten und Ergebnisse zurück (FrTp SWS S. 19). Nach unten übergibt FrTp N-PDUs mit FrIf_Transmit ([SWS_FrTp_01050]). FrIf meldet sich mit FrTp_RxIndication, FrTp_TxConfirmation und FrTp_TriggerTransmit zurück (FrTp SWS S. 21). Der EcuM ruft FrTp_Init und FrTp_Shutdown auf (FrTp SWS S. 19). Der BSW-Scheduler ruft FrTp_MainFunction auf ([SWS_FrTp_00162], FrTp SWS S. 81).

Ein Unterschied zwischen den Releases: Spätere Fassungen schalten einen L-SDU-Router (LSduR) zwischen FrTp und FrIf (FrTp SWS S. 19). Für R20-11 gilt die direkte Schnittstelle zu FrIf, wie sie [SWS_FrTp_00577] und [SWS_FrTp_01050] festlegen.

Kontextdiagramm: FrTp liegt zwischen PduR und FrIf und wird von EcuM und BSW-Scheduler gesteuert. Quellen: FrTp SWS S. 19, FrTp SWS S. 21, [SWS_FrTp_00577]

Das Modul kennt zwei Zustände, FRTP_OFF und FRTP_ON ([SWS_FrTp_01028]). Welcher gilt, hält die Statusvariable FrTpState fest ([SWS_FrTp_01029], [SWS_FrTp_01106]). Nach dem Einschalten ist FrTp in FRTP_OFF ([SWS_FrTp_01030]). Erst ein erfolgreiches FrTp_Init mit Zeiger auf FrTp_ConfigType schaltet nach FRTP_ON ([SWS_FrTp_01032], [SWS_FrTp_00147], [SWS_FrTp_01194]). Segmentierung und Reassemblierung laufen nur in FRTP_ON ([SWS_FrTp_01033]). FrTp_Shutdown beendet alle offenen Verbindungen, indem es den Betrieb einfach stoppt. Es gibt die Ressourcen frei und führt nach FRTP_OFF zurück ([SWS_FrTp_00148], [SWS_FrTp_01036]).

Zustandsdiagramm: Nur zwischen FrTp_Init und FrTp_Shutdown verarbeitet FrTp Daten. Quellen: [SWS_FrTp_01030], [SWS_FrTp_01032], [SWS_FrTp_01036], FrTp SWS S. 38

FrTp_MainFunction plant das Modul ein und ist der Einstiegspunkt aller Verarbeitungsaufgaben ([SWS_FrTp_00203], [SWS_FrTp_00580]). Sie muss mindestens einmal je FlexRay-Zyklus laufen ([SWS_FrTp_01152]). Die Callbacks setzen dagegen im Wesentlichen nur Flags: TX_SDU_AVAILABLE existiert je Kanal ([SWS_FrTp_00415], [SWS_FrTp_00416]). RX_PDU_AVAILABLE existiert je empfangbarer N-PDU und wird nach der Verarbeitung gelöscht ([SWS_FrTp_00418], [SWS_FrTp_00421]).

Übertragungsvarianten nach ISO 10681-2

FrTp unterstützt sechs Rahmenfolgen. Sie unterscheiden sich in drei Punkten: ob die Nachricht segmentiert wird, ob der Empfänger quittiert und ob die Länge bei Übertragungsbeginn bekannt ist (FrTp SWS S. 27, FrTp SWS S. 31):

Variante	Kennzeichnende Rahmen	Beleg
unsegmentiert, ohne Quittung, Länge bekannt	STFU	[SWS_FrTp_01007]
unsegmentiert, mit Quittung, Länge bekannt	STFA → FC.ACK	[SWS_FrTp_01008]
segmentiert, ohne Quittung, Länge bekannt	STFU, FC.CTS, CF, CFEOB, LF	[SWS_FrTp_01009]
segmentiert, mit Quittung, Länge bekannt	STFA, FC.CTS, CF, CFEOB, LF, FC.ACK	[SWS_FrTp_01010]
segmentiert, ohne Quittung, Länge unbekannt	wie oben, Gesamtlänge erst im LF	[SWS_FrTp_01011], [SWS_FrTp_01067]
segmentiert, mit Quittung, Länge unbekannt	wie oben, zusätzlich FC.ACK	[SWS_FrTp_01012]

In den segmentierten, quittierten Varianten dürfte das FC.ACK nach dem LastFrame folgen und den Transfer abschließen. Frage Q-f3c70b1506e2cde4 (offen) Das ist eine Interpretation der Bildtexte, deren Reihenfolge nicht eindeutig ist (FrTp SWS S. 29). Das folgende Diagramm zeigt den segmentierten Grundfall ohne Quittung.

Sequenzdiagramm: Der Empfänger gibt jeden Block per FC.CTS frei, und CFEOB schließt einen Block ab. Quellen: [SWS_FrTp_01009], FrTp SWS S. 28

Übertragung mit unbekannter Länge:

• Sie wird per Compilerschalter aktiviert ([SWS_FrTp_01062]).
• Gestartet wird sie mit FrTp_Transmit und der Länge 0 ([SWS_FrTp_01064], [SWS_FrTp_01043]).
• Sie endet, wenn der gemeldete Längenparameter 0 ist ([SWS_FrTp_01066]).
• Den Zustand führt das Flag TX_SDU_UNKNOWN_MSG_LENGTH je Kanal ([SWS_FrTp_01101], [SWS_FrTp_01102]).
• Der Empfänger ruft PduR_FrTpStartOfReception mit erwarteter Länge 0 auf ([SWS_FrTp_01184]).
• Auf einer 1:n-Verbindung weist FrTp_Transmit solche Aufträge mit E_NOT_OK ab und meldet FRTP_E_SEG_ERROR ([SWS_FrTp_01187], FrTp SWS S. 47).

Verbindungen, Kanäle und PDU-Pools

Jede Kommunikationsbeziehung ist eine eigene FrTpConnection. Ihre Anzahl ist post-build konfigurierbar ([SWS_FrTp_01014], [SWS_FrTp_01015]). Jede Verbindung hat ein modulweit eindeutiges Adresspaar und eine eindeutige FRTP_SDUID ([SWS_FrTp_01017], [SWS_FrTp_01018]). Mehrere Verbindungen können sich eine FrTpConnectionControl und einen FrTpTxPduPool teilen ([SWS_FrTp_01022], [SWS_FrTp_01020]). Zur Laufzeit arbeiten mehrere FrTpChannel parallel; ihre Zahl legt FrTpChanNum fest ([SWS_FrTp_00088], [SWS_FrTp_00228]). Für Senden und Empfangen wechseln die Kanäle jeweils zwischen „idle“ und „busy“ ([SWS_FrTp_01117], [SWS_FrTp_01025]).

Kontextdiagramm: Ein Halbduplex-Kanal verweist auf eine Tx- und eine Rx-Verbindung. Beide referenzieren Steuerparameter und einen Tx-PDU-Pool. Quellen: FrTp SWS S. 39, [SWS_FrTp_01020], [SWS_FrTp_01088]

Adressen:

• Beim Senden übernimmt FrTp Adressen aus den Metadaten SOURCE_ADDRESS_16 und TARGET_ADDRESS_16. Konfigurierte FrTpLa/FrTpRa haben dabei Vorrang ([SWS_FrTp_01204], [SWS_FrTp_01205]).
• Beim Empfang reicht FrTp die Adressen als Metadaten nach oben. Dieselben Adressen verwendet es für FlowControl ([SWS_FrTp_01206]).

Bandbreite verteilt FrTp über die Pools:

• Die Tx-N-PDUs eines Pools stehen in aufsteigender Netzplan-Reihenfolge und dürfen unterschiedlich lang sein ([SWS_FrTp_01088], [SWS_FrTp_01089]).
• Der TxPduPendingCounter eines Kanals zählt unbestätigte N-PDUs ([SWS_FrTp_01091], [SWS_FrTp_01092]). Eine Verbindung wird nur bearbeitet, wenn er 0 ist ([SWS_FrTp_01094]). So können Consecutive Frames sich nicht überholen (FrTp SWS S. 61).
• Aktive Verbindungen kommen abwechselnd an die Reihe ([SWS_FrTp_01096]).
• Bei Bandbreitenbegrenzung gelten drei Regeln: StartFrame und FlowControl gehen im ersten PDU des Pools ([SWS_FrTp_01174], [SWS_FrTp_01177]). Der Sender nutzt nur BC.MPPC PDUs ([SWS_FrTp_01175]). Pools dürfen sich überlappen ([SWS_FrTp_01176]).
• FrIf muss die PDUs einer Verbindung in aufsteigender Reihenfolge innerhalb eines Jobs einplanen (FrTp SWS S. 122).

Sendepfad: von FrTp_Transmit bis PduR_FrTpTxConfirmation

Jedes Senden beginnt mit FrTp_Transmit ([SWS_FrTp_00136], [SWS_FrTp_00149]). Der Aufruf setzt TX_SDU_AVAILABLE nur, wenn die TxPduId gültig und ein Kanal frei ist ([SWS_FrTp_01039]). Andernfalls endet er mit E_NOT_OK. Dasselbe gilt, wenn für dieselbe Adresse schon eine Übertragung läuft ([SWS_FrTp_01041], [SWS_FrTp_01200]).

Die eigentliche Arbeit macht FrTp_MainFunction:

1. Sie erfragt die verfügbare Länge per PduR_FrTpCopyTxData ([SWS_FrTp_01042]).
2. Sie belegt den ersten freien FrTpTxPdu ([SWS_FrTp_01045]).
3. Sie entscheidet über die Segmentierung ([SWS_FrTp_01048]).
4. Sie kopiert Daten in PDU-Länge ([SWS_FrTp_01123]).
5. Sie übergibt die N-PDU mit exakter Länge an FrIf_Transmit ([SWS_FrTp_01051]).

Den Ablauf zeigt FrTp SWS S. 44.

Aktivitätsdiagramm: Entscheidung zwischen unsegmentierter und segmentierter Übertragung, einschließlich Abbruch auf 1:n-Verbindungen. Quellen: [SWS_FrTp_01047], [SWS_FrTp_01048], [SWS_FrTp_01208], FrTp SWS S. 51

Wichtig für den Durchsatz: Ist kein PDU frei, stellt FrTp die Verbindung bis zum nächsten MainFunction-Aufruf zurück ([SWS_FrTp_01047]).

Nach jeder N-PDU ruft FrIf FrTp_TxConfirmation auf. Das setzt den FrTpTxPdu auf „idle“ ([SWS_FrTp_01052], [SWS_FrTp_01054]). Kanal und Flag werden frei, sobald drei Bedingungen erfüllt sind: alle Daten gesendet, positiv bestätigt und, falls konfiguriert, quittiert ([SWS_FrTp_01056], [SWS_FrTp_01057]). PduR_FrTpTxConfirmation kommt nach jedem angenommenen Auftrag, mit E_OK nur im Erfolgsfall ([SWS_FrTp_01058]). Für das Senden gibt es zwei Pufferzugriffsarten: „Immediate“ und „Decoupled Buffer Access“ ([SWS_FrTp_01084]). Bei „Decoupled“ holt FrIf die Daten später über FrTp_TriggerTransmit. Dieser Aufruf kopiert Address Information, PCI und Nutzdaten in den bereitgestellten Puffer ([SWS_FrTp_01060], [SWS_FrTp_01061], FrTp SWS S. 50).

Sequenzdiagramm: Der Auftrag kommt synchron an und wird asynchron in der MainFunction abgearbeitet; optional folgt TriggerTransmit (Decoupled). Quellen: FrTp SWS S. 44, FrTp SWS S. 50, [SWS_FrTp_01058]

Empfangspfad und Reassemblierung

Der Empfang beginnt mit FrTp_RxIndication ([SWS_FrTp_00137]). FrTp verarbeitet eine N-PDU nur, wenn zwei Bedingungen erfüllt sind ([SWS_FrTp_01069], [SWS_FrTp_01071]):

• Die RxPduId ist gültig.
• Die Zieladresse entspricht FrTpLa und die Quelladresse FrTpRa.

Sonst wird die N-PDU ignoriert ([SWS_FrTp_01072]). Ist kein Rx-Kanal frei, endet die Verarbeitung, und FrTp meldet FRTP_E_NO_CHANNEL ([SWS_FrTp_01076], [SWS_FrTp_01186]). Einen StartFrame legt FrTp in einem lokalen Puffer ab. So kann ein Gateway ihn auch bei kurzzeitigem Ressourcenmangel korrekt verarbeiten (FrTp SWS S. 56).

Bei einer neuen Verbindung ruft FrTp PduR_FrTpStartOfReception auf. Übergeben werden die erwartete Länge sowie Inhalt und Größe des StartFrames ([SWS_FrTp_01078], [SWS_FrTp_01193]). Wo dieser Aufruf erfolgt, zeigen die R20-11-Schaubilder in zwei Varianten: in FrTp_RxIndication (FrTp SWS S. 55) und in FrTp_MainFunction (FrTp SWS S. 86). R23-11 erlaubt ausdrücklich beides (FrTp SWS S. 54).

Danach kopiert FrTp die Fragmente per PduR_FrTpCopyRxData und sendet FlowControl, wo das Protokoll es verlangt ([SWS_FrTp_01138], [SWS_FrTp_01080]). Den Kanal gibt es frei, wenn alle Daten empfangen und alle FlowControls bestätigt sind ([SWS_FrTp_01081]). PduR_FrTpRxIndication folgt immer, wenn PduR_FrTpStartOfReception erfolgreich war ([SWS_FrTp_01083]).

Sequenzdiagramm: Der Callback prüft und puffert, die MainFunction reassembliert und sendet FlowControl. Quellen: FrTp SWS S. 55, [SWS_FrTp_01074], [SWS_FrTp_01083]

Abbruch und Laufzeitparameter

Ob Sendeabbruch verfügbar ist, legt FrTpTransmitCancellation statisch fest; ausgelöst wird er mit FrTp_CancelTransmit ([SWS_FrTp_01097], [SWS_FrTp_00384]). Die Wirkung hängt vom Fortschritt ab:

• Ist der Auftrag angenommen, aber noch nicht gestartet, wird die Verbindung sofort frei. Der Empfänger bemerkt nichts ([SWS_FrTp_00385], FrTp SWS S. 63).
• Läuft die Übertragung, stoppt FrTp sie mit E_OK ([SWS_FrTp_01116]).
• E_NOT_OK folgt, wenn keine Verbindung aktiv ist oder die letzte N-PDU einer unquittierten Übertragung schon an FrIf übergeben wurde ([SWS_FrTp_01116]).

Im segmentierten Fall läuft beim Empfänger ein Timeout ab, der den Empfang beendet (FrTp SWS S. 59).

Sequenzdiagramm: Bricht der Sender eine laufende segmentierte Übertragung ab, beendet der Empfänger den Empfang per Timeout. Quellen: [SWS_FrTp_01116], FrTp SWS S. 69

FrTp_CancelReceive bricht einen laufenden Empfang ab, wenn die RxPduId gültig ist, und liefert dann E_OK ([SWS_FrTp_01181], [SWS_FrTp_01183]). Bei unsegmentiertem Empfang oder laufendem LastFrame lehnt die Funktion ab ([SWS_FrTp_01182]). FrTp_ChangeParameter ändert zur Laufzeit die BandwidthControl-Werte FrTpSCexp und FrTpMaxNbrOfNPduPerCycle ([SWS_FrTp_00242]). Das Bitlayout entspricht dem des FC(CTS)-Rahmens ([SWS_FrTp_01195]). Die Parameterkennung dafür ist TP_BC (ComStack Types S. 18). Während eines laufenden Empfangs wird die Änderung abgewiesen ([SWS_FrTp_01115]). Nach erfolgreicher Änderung nutzt die Verbindung die neuen Werte ([SWS_FrTp_01156]).

Verhalten im Fehlerfall

Entwicklungsfehler sind in [SWS_FrTp_01201] festgelegt:

• FRTP_E_UNINIT: Aufruf ohne Initialisierung; ausgenommen sind FrTp_Init und FrTp_GetVersionInfo.
• FRTP_E_PARAM_POINTER: NULL-Zeiger.
• FRTP_E_INVALID_PDU_SDU_ID: ungültige SDU- oder PDU-ID.
• FRTP_E_INVALID_PARAMETER: ungültiger Parameter.
• FRTP_E_UMSG_LENGTH_ERROR: unbekannte Länge ohne passende Konfiguration ([SWS_FrTp_01134]).
• ein Fehlercode für eine fehlgeschlagene Initialisierung.

Die APIs prüfen IDs und Zeiger und liefern bei Fehlern E_NOT_OK, wo sie einen Rückgabewert haben ([SWS_FrTp_01139], [SWS_FrTp_01145], [SWS_FrTp_01147]). Laufzeitfehler sind FRTP_E_SEG_ERROR (0x05) und FRTP_E_NO_CHANNEL (0x07). Sie gehen über Det_ReportRuntimeError ([SWS_FrTp_01208], [SWS_FrTp_00577]).

In drei Fällen bricht der Sender ab und meldet PduR_FrTpTxConfirmation mit E_NOT_OK:

• Ein FlowControl hat ungültigen Flow Status oder OVFLW/ABT ([SWS_FrTp_01198]).
• ACK_RET verweist auf eine Position außerhalb des Puffers ([SWS_FrTp_01199]).
• Eine 1:n-Verbindung müsste segmentiert werden (FrTp SWS S. 51).

Eine FrTp_TxConfirmation mit E_NOT_OK gibt auf beiden Seiten den Kanal frei ([SWS_FrTp_01056], [SWS_FrTp_01081]). Das Flag RX_ERROR merkt sich einen Empfangsfehler, bis FlowControl gesendet werden darf. Nach der Reaktion (Retry, Negativquittung oder Abbruch) wird es gelöscht ([SWS_FrTp_00429], [SWS_FrTp_00430]). Auf 1:n-Verbindungen gibt es weder Quittung noch Retry ([SWS_FrTp_00598]).

Timer und Timeouts folgen den Tabellen der Spezifikation ([SWS_FrTp_01099], [SWS_FrTp_01100], FrTp SWS S. 67). Die Konfiguration muss folgende Bedingungen einhalten:

• FRTP_TIMEOUT_BS > FRTP_TIME_BR + FRTP_TIME_AR ([SWS_FrTp_00599])
• FRTP_TIMEOUT_CR > FRTP_TIME_CS + FRTP_TIME_AS ([SWS_FrTp_01153])
• eine Schranke für den Separationszyklus-Exponenten ([SWS_FrTp_00180])

Liefert der PduR beim Senden BUFREQ_E_BUSY, versucht FrTp es bis zu FrTpTimeCs-mal erneut ([SWS_FrTp_01196]). Die Zähler sind begrenzt ([SWS_FrTp_01105], [SWS_FrTp_01114]). Was bei Erreichen eines Limits geschieht, legt [SWS_FrTp_01113] fest; die zugehörige Tabelle liegt hier nicht vor. Fehlt dem Empfänger ein Puffer, sendet er FC.WAIT. Die Zahl dieser Rahmen begrenzt FrTpMaxFCWait (FrTp SWS S. 69).

Sequenzdiagramm: Fehlt der Puffer, sendet der Empfänger FC.WAIT, bis das Zählerlimit greift; danach setzt FC.CTS die Übertragung fort. Quellen: [SWS_FrTp_01105], [SWS_FrTp_01114], FrTp SWS S. 70

Weiterführende Detailbelege

• Lebenszyklus und Scheduling: [SWS_FrTp_01028], [SWS_FrTp_01152], FrTp SWS S. 88.
• Protokollvarianten: [SWS_FrTp_01007] bis [SWS_FrTp_01012] mit den Schaubildern ab FrTp SWS S. 27.
• Sendepfad und Bestätigung: [SWS_FrTp_01042], [SWS_FrTp_01058], FrTp SWS S. 85.
• Empfangspfad: [SWS_FrTp_01078], [SWS_FrTp_01083].
• Bandbreite und Pools: [SWS_FrTp_01096], [SWS_FrTp_01175], FrTp SWS S. 60, FrTp SWS S. 134.
• Retry-Szenarien (API-Wiederholung gegenüber PDU-Wiederholung): FrTp SWS S. 106.
• Fehlerkatalog: [SWS_FrTp_01201], [SWS_FrTp_01208].