Diagnostic Log and Trace (DLT)

Die synchrone und nicht reentrante Funktion Dlt_Init (Service-ID 0x01, verfügbar über die Header-Datei Dlt.h) initialisiert das Modul Diagnostic Log and Trace (DLT) in der Classic-Plattform [SWS_Dlt_00239]. Sie nimmt über den Parameter config einen Zeiger auf die modulspezifische Konfigurationsstruktur vom Typ Dlt_ConfigType entgegen und liefert keinen Rückgabewert zurück [SWS_Dlt_00239].

Für den Aufrufkontext und das zeitliche Zusammenspiel mit anderen BSW-Modulen gelten spezifische Randbedingungen:

• Initialisierungsreihenfolge: Das DLT-Modul verwendet den NVRam Manager und muss sehr spät in der Startphase des Steuergeräts initialisiert werden [SWS_Dlt_00239]. Der Aufruf der Funktion Dlt_Init sollte zwingend erst nach der vollständigen Initialisierung des NVRam Managers erfolgen [SWS_Dlt_00239].
• Persistente Daten: Wenn der Konfigurationsparameter DltGeneralNvRAMSupport auf TRUE gesetzt ist, nutzt das DLT-Modul in Dlt_Init die Schnittstelle NvM_ReadBlock des NVRAM-Managers, um persistente Werte für erforderliche Variablen wiederherzustellen [SWS_Dlt_00453].
• Pufferverarbeitung: Sobald das Modul durch Dlt_Init initialisiert wurde und der optionale Timer DltGeneralStartUpDelayTimer abgelaufen ist, werden sämtliche zwischenzeitlich gepufferten Log- und Trace-Daten verarbeitet und gemäß Spezifikation versendet [SWS_Dlt_00005].

Da die Funktion als nicht reentrant spezifiziert ist, muss der aufrufende Kontext sicherstellen, dass Dlt_Init während der Ausführung nicht parallel oder unterbrechend erneut betreten wird [SWS_Dlt_00239].

Die synchrone und reentrante Funktion Dlt_SendTraceMessage dient Basissoftwaremodulen (BSW) sowie Software-Komponenten (SW-C) zur Übertragung von Trace-Parametern an das Dlt-Modul [SWS_Dlt_00243].

Parameter und Aufrufkontext

Beim Aufruf werden die Modul- bzw. Port-Kennung über sessionId, Metadaten zur Nachrichtenfilterung über traceInfo sowie der Nutzdatenpuffer über traceData samt Längenangabe traceDataLength übergeben [SWS_Dlt_00243]. Das Modul kann Trace-Nachrichten bereits puffern, selbst wenn Dlt noch nicht initialisiert wurde [SWS_Dlt_00003].

Rückgabewerte und Fehlerbehandlung

Der Dienst signalisiert den Status über spezifische Rückgabewerte [SWS_Dlt_00243]:

• E_OK: Die Operation wurde erfolgreich ausgeführt.
• DLT_E_MSG_TOO_LARGE: Die Nachricht übersteigt die zulässige Größe aller zugewiesenen Log-Kanäle.
• DLT_E_NO_BUFFER: Unzureichender Pufferspeicher; die Nachricht kann für mindestens einen Log-Kanal nicht zwischengespeichert werden.
• DLT_E_UNKNOWN_SESSION_ID: Die übergebene sessionId ist dem Modul unbekannt.

Zusammenspiel mit Hook-Funktionen

Da Dlt_SendTraceMessage als Schnittstelle für SW-Cs spezifiziert ist, existiert für generierte Hook-Funktionen eine äquivalente interne Implementierung [SWS_Dlt_00285], welche Trace-Nachrichten im Non-Verbose-Modus absetzt [SWS_Dlt_00277].

Die synchrone und reentrante Funktion Dlt_SendLogMessage (Service-ID 0x03) dient Basissoftware-Modulen (BSW) sowie Software-Komponenten (SW-C) als standardisierte Schnittstelle zum Versenden von Log-Nachrichten [SWS_Dlt_00241]. Der Aufruf erfolgt über die Header-Datei Dlt.h, und aufgrund der Reentranz ist die Funktion für den nebenläufigen Einsatz ausgelegt [SWS_Dlt_00241].

Beim Aufruf der Funktion sind vier Übergabeparameter erforderlich, während keine Ausgabeparameter verwendet werden [SWS_Dlt_00241]:

• sessionId: Repräsentiert die Sitzungskennung. Für SW-Cs ist dieser Parameter als portbezogener Argumentwert unsichtbar, während BSW-Module direkt ihre Modulnummer übergeben.
• logInfo: Zeiger auf eine konstante Struktur, welche die relevanten Metadaten zur Filterung der Log-Nachricht enthält.
• logData: Zeiger auf das Byte-Array mit den zu protokollierenden Daten, das die eigentliche Nutzlast (Payload) der Nachricht bildet.
• logDataLength: Numerische Länge des Datenpuffers logData.

Die Fehlerbehandlung erfolgt unmittelbar über den Rückgabewert vom Typ Std_ReturnType, der den Erfolg der Operation oder spezifische Fehlerzustände anzeigt [SWS_Dlt_00241]:

• DLT_OK: Die Log-Nachricht wurde erfolgreich angenommen und verarbeitet.
• DLT_E_MSG_TOO_LARGE: Die Nachricht übersteigt die maximal zulässige Puffergröße für alle zugewiesenen Log-Kanäle.
• DLT_E_NO_BUFFER: Die Nachricht konnte auf keinem der zugewiesenen Log-Kanäle zwischengespeichert werden.
• DLT_E_UNKNOWN_SESSION_ID: Die übergebene Sitzungs-ID ist ungültig oder dem Modul nicht bekannt.

Verwendung

Die synchrone Funktion Dlt_UnregisterContext (Service-ID 0x16) wird über die Header-Datei Dlt.h bereitgestellt und muss aufgerufen werden, wenn ein Software-Modul gestoppt wird [SWS_Dlt_00769]. Sie dient der Abmeldung eines zuvor registrierten Kontexts einer Anwendung.

Die Funktion erwartet drei Eingabeparameter [SWS_Dlt_00769]:

• sessionId: Modulnummer; entspricht der Modul-ID innerhalb des BSW oder dem port-spezifisch definierten Argumentwert innerhalb einer Software-Komponente (SW-C) [SWS_Dlt_00769].
• appId: Die Kennung der übergeordneten Applikation (Application ID) [SWS_Dlt_00769].
• contextId: Die Kennung des abzumeldenden Kontexts (Context ID) [SWS_Dlt_00769].

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert vom Typ Std_ReturnType gibt Auskunft über das Ergebnis der Ausführung [SWS_Dlt_00769]:

• E_OK: Die angeforderte Operation wurde erfolgreich abgeschlossen [SWS_Dlt_00769].
• DLT_E_CONTEXT_NOT_YET_REG: Der Kontext des Software-Moduls wurde vorab nicht registriert [SWS_Dlt_00769].
• DLT_E_UNKNOWN_SESSION_ID: Die übergebene Session-ID ist unbekannt [SWS_Dlt_00769].

Nebenläufigkeit und Einschränkungen

Die Funktion ist als reentrant spezifiziert und verhält sich synchron [SWS_Dlt_00769]. Aufrufende Module müssen sicherstellen, dass die übergebene Session-ID gültig ist und der Kontext vor dem Beenden tatsächlich registriert war, um Fehler bei der Deregistrierung zu vermeiden [SWS_Dlt_00769].

Verwendung und Aufrufkontext

Die synchrone Schnittstelle Dlt_DetForwardErrorTrace mit der Service-ID 0x07 dient dazu, gemeldete Entwicklungsfehler aus dem Default Error Tracer (DET) an das Dlt-Modul weiterzuleiten [SWS_Dlt_00432]. Das Dlt-Modul stellt diesen Dienst zur Verfügung, um die geforderte Fan-Out-Fähigkeit des DET für Fehlermeldungen zu gewährleisten [SWS_Dlt_00430]. Die Deklaration dieser C-Funktion ist über die Header-Datei Dlt_Det.h eingebunden [SWS_Dlt_00432].

Parameter und Schnittstellenspezifikation

Die Funktion nimmt vier obligatorische Eingabeparameter entgegen und definiert weder Rückgabewerte noch Ausgabeparameter [SWS_Dlt_00432]:

• moduleId: Modul-ID des aufrufenden Software-Moduls, in welchem der Fehler auftrat.
• instanceId: Bezeichner der indexbasierten Modulinstanz (Zählung beginnt bei 0; Einzelinstanz-Module übergeben 0).
• apiId: Kennung des betroffenen API-Dienstes (definiert in der Spezifikation des aufrufenden Moduls).
• errorId: Kennung des festgestellten Entwicklungsfehlers (definiert in der Spezifikation des aufrufenden Moduls).

Nebenläufigkeit und Fehlerbehandlung

Die Ausführung erfolgt synchron zur aufrufenden Fehlererfassung. Als nicht reentrante Funktion (Non Reentrant) erfordert die Schnittstelle zwingend, dass aufruferseitig konkurrierende Ausführungen vermieden werden [SWS_Dlt_00432]. Spezifische Fehlercodes, Fehlerrückmeldungen oder gesonderte DET- bzw. DEM-Meldungen sind für diesen Service in der Spezifikation nicht vorgesehen [SWS_Dlt_00432].

Die synchrone Funktion Dlt_SetTraceStatus dient dem Einstellen des Trace-Status für ein bestimmtes Tupel aus Application-ID und Context-ID [SWS_Dlt_00254]. Sie ist über die Header-Datei Dlt.h definiert und besitzt die Service-ID 0x09 [SWS_Dlt_00254].

Verwendung

Für den Aufruf sind drei Eingangsparameter erforderlich [SWS_Dlt_00254]:

• appId: Die ID der Software-Komponente (Typ Dlt_ApplicationIDType).
• contextId: Die ID des Kontexts (Typ Dlt_ContextIDType).
• newTraceStatus: Der neu zu setzende Trace-Status als Wahrheitswert (Typ boolean).

Fehlerbehandlung und Rückgabewerte

Die Funktion gibt synchron einen Status vom Typ Std_ReturnType zurück [SWS_Dlt_00254]:

• E_OK: Es ist kein Fehler aufgetreten und der Status wurde erfolgreich übernommen.
• E_NOT_OK: Der Trace-Status konnte nicht geändert werden. Spezifische DET-Fehlermeldungen werden in der Funktionsspezifikation nicht genannt (Interpretation: Ein Fehler dürfte vermutlich bei ungültigen Bezeichnern oder fehlerhaftem Modulzustand vorliegen). Frage Q-77e190707462c8f1 (offen)

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dlt_00254]. Daher darf sie nicht nebenläufig oder unterbrechend ohne geeignete Synchronisation durch den Aufrufer ausgeführt werden.

Verwendung

Die Funktion Dlt_StoreConfiguration ([SWS_Dlt_00736]) dient dem Sichern der aktuellen Dlt-Konfiguration in den nichtflüchtigen Speicher (NvRAM). Die Speicherung erfolgt intern über einen synchronen Aufruf der Schnittstelle NvM_WriteBlock() des NVRAM Managers ([SWS_Dlt_00736]). Bereitgestellt wird die API über den Header Dlt.h mit der Service-ID 0x1a.

Die Funktion besitzt die Signatur Std_ReturnType Dlt_StoreConfiguration(void) und verarbeitet weder Eingangs-, Ausgangs- noch Ein-/Ausgangsparameter ([SWS_Dlt_00736]).

Fehlerbehandlung und Rückgabewerte

Als synchroner Dienst liefert die Funktion unmittelbar einen Statuscode vom Typ Std_ReturnType an den Aufrufer zurück ([SWS_Dlt_00736]):

• E_OK: Die Konfiguration wurde fehlerfrei an das NvRAM übergeben ([SWS_Dlt_00736]).
• E_NOT_OK: Beim Speichern der Dlt-Konfiguration ist ein Fehler aufgetreten ([SWS_Dlt_00736]).
• DLT_E_NOT_SUPPORTED: Der Service zur Konfigurationsspeicherung wird vom Modul nicht unterstützt ([SWS_Dlt_00736]).

Nebenläufigkeit und Einschränkungen

Gemäß [SWS_Dlt_00736] ist Dlt_StoreConfiguration als nicht reentrant (Non Reentrant) spezifiziert. Die Funktion darf daher nicht nebenläufig aus verschiedenen Tasks oder Kontexten heraus ausgeführt werden, sodass auf Aufruferseite für einen sequenziellen Ablauf gesorgt werden muss.

Verwendung

Die synchrone Funktion Dlt_ResetToFactoryDefault wird über den Header Dlt.h bereitgestellt und nimmt keine Übergabeparameter entgegen [SWS_Dlt_00739]. Ihr primärer Zweck ist das Zurücksetzen der Dlt-Laufzeitkonfiguration: Sie setzt das Log-Level sowie den Trace-Status auf die persistent abgelegten Standardwerte zurück [SWS_Dlt_00739]. Ist zusätzlich die NvRAM-Unterstützung im Dlt-Modul aktiviert, bewirkt der Aufruf das vollständige Löschen aller im NvM hinterlegten Dlt-Werte [SWS_Dlt_00739].

Rückgabewerte und Fehlerbehandlung

Das Ergebnis der Operation wird synchron über den Rückgabewert vom Typ Std_ReturnType signalisiert [SWS_Dlt_00739]:

• E_OK: Die Konfiguration wurde erfolgreich auf die Standardwerte zurückgesetzt [SWS_Dlt_00739].
• E_NOT_OK: Das Zurücksetzen der Konfiguration ist fehlgeschlagen [SWS_Dlt_00739].

Spezifische DET- oder DEM-Fehlermeldungen sind für diesen Service im vorliegenden Spezifikationsumfang nicht definiert.

Nebenläufigkeit und Einschränkungen

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert (Service-ID 0x06) [SWS_Dlt_00739]. Ein nebenläufiger oder unterbrechender Aufruf aus verschiedenen Tasks oder Kontexten ist daher unzulässig und muss durch den Aufrufer verhindert werden.

Die Funktion Dlt_RxIndication dient der Indikation einer empfangenen PDU aus einem unterlagerten Kommunikationsschnittstellenmodul an das DLT-Modul [SWS_Dlt_00272]. Sie ist über den Header Dlt.h verfügbar und besitzt die Service-ID 0x42 [SWS_Dlt_00272].

Der Aufruf erfolgt mit synchroner Semantik und liefert keinen Rückgabewert (void) [SWS_Dlt_00272]. An die Funktion werden zwei Eingangsparameter übergeben:

• RxPduId: Identifikator der empfangenen PDU (vom Typ PduIdType) [SWS_Dlt_00272].
• PduInfoPtr: Zeiger auf eine Struktur vom Typ PduInfoType. Diese enthält die Länge der empfangenen PDU (SduLength), einen Zeiger auf den Puffer mit den PDU-Nutzdaten (SduDataPtr) sowie zugehörige Metadaten der PDU [SWS_Dlt_00272].

Hinsichtlich der Nebenläufigkeit und des Ausführungskontexts ist die Funktion reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe PDU-ID [SWS_Dlt_00272]. Das aufrufende unterlagerte Modul darf dieselbe RxPduId folglich nicht nebenläufig verarbeiten lassen, während parallele Aufrufe mit verschiedenen PDU-IDs zulässig sind [SWS_Dlt_00272].

Die synchrone Funktion Dlt_TriggerTransmit dient gemäß [SWS_Dlt_00754] dazu, SDU-Daten auf Anfrage einer unterlagerten Schicht in einen bereitgestellten Puffer zu kopieren. Sie ist in Dlt.h deklariert und besitzt die Service-ID 0x41.

Beim Aufruf werden folgende Parameter übergeben:

• TxPduId: Bezeichner der SDU, deren Übertragung angefordert wird.
• PduInfoPtr: Zeiger auf eine Struktur vom Typ PduInfoType. Der Aufrufer übergibt über SduDataPtr den Zielpuffer und über SduLength die maximal verfügbare Puffergröße.

Innerhalb der Funktion prüft das Modul gemäß [SWS_Dlt_00754], ob die verfügbaren Daten in die übergebene Puffergröße passen:

• Passen die Daten, kopiert die Funktion die Nutzdaten in SduDataPtr, aktualisiert SduLength mit der Anzahl der tatsächlich kopierten Bytes und liefert E_OK zurück.
• Reicht der Puffer nicht aus, liefert die Funktion E_NOT_OK zurück, ohne PduInfoPtr zu modifizieren.

Wird E_NOT_OK zurückgegeben, wurden keine SDU-Daten kopiert. Der Aufrufer darf PduInfoPtr in diesem Fall nicht weiterverwenden, da er auf ungültige Daten verweisen oder ein NULL-Zeiger sein kann [SWS_Dlt_00754].

Hinsichtlich der Nebenläufigkeit ist Dlt_TriggerTransmit reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe TxPduId [SWS_Dlt_00754].

Verwendung und Aufrufkontext

Die Funktion Dlt_TxConfirmation dient als Bestätigungsschnittstelle der unterlagerten Kommunikationsschicht (lower layer communication interface module) gegenüber dem Modul Diagnostic Log and Trace (DLT) [SWS_Dlt_00273]. Sie informiert das DLT-Modul synchron darüber, ob eine zuvor angeforderte PDU erfolgreich übertragen werden konnte oder ob die Übertragung gescheitert ist [SWS_Dlt_00273]. Die Funktion besitzt die Service-ID 0x40 und wird über die Header-Datei Dlt.h bereitgestellt [SWS_Dlt_00273].

Die Schnittstelle besitzt keinen Rückgabewert (void) und erwartet zwei Übergabeparameter [SWS_Dlt_00273]:

• TxPduId: Die Kennung der übertragenen PDU vom Typ PduIdType.
• result: Der Übertragungsstatus vom Typ Std_ReturnType; hierbei signalisiert E_OK die erfolgreiche Übertragung und E_NOT_OK ein Scheitern der PDU-Übertragung.

Fehlerbehandlung und Nebenläufigkeit

Eine explizite Fehlerbehandlung mit Fehlerrückgabewerten oder spezifischen DET- bzw. DEM-Meldungen ist für diesen Aufruf nicht spezifiziert; das Scheitern eines Sendevorgangs wird dem DLT-Modul rein über den Parameterwert result = E_NOT_OK mitgeteilt [SWS_Dlt_00273].

Für die Ausführung gilt eine differenzierte Reentranz-Bedingung: Dlt_TxConfirmation ist reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe PDU-ID [SWS_Dlt_00273]. Aufrufende Treiber oder Schnittstellen müssen daher sicherstellen, dass gleichzeitige Aufrufe mit identischer TxPduId ausgeschlossen sind, während Bestätigungen für unterschiedliche PDUs nebenläufig eintreffen dürfen.

Die Funktion Dlt_TpTxConfirmation dient als synchrone Bestätigungsfunktion des Dlt-Moduls nach dem Senden einer Transport-I-PDU [SWS_Dlt_00756]. Sie ist über die Header-Datei Dlt.h mit der Service-ID 0x48 verfügbar [SWS_Dlt_00756].

Verwendung und Semantik

Der Aufruf erfolgt, nachdem eine I-PDU auf dem jeweiligen Netzwerk übertragen wurde [SWS_Dlt_00756]. Die Funktion besitzt die Signatur void Dlt_TpTxConfirmation (PduIdType id, Std_ReturnType result) und liefert keinen Rückgabewert zurück [SWS_Dlt_00756]:

• id (Eingangsparameter, Typ PduIdType): Eindeutige Identifikation der übertragenen I-PDU [SWS_Dlt_00756].
• result (Eingangsparameter, Typ Std_ReturnType): Gibt den Übertragungsstatus an und zeigt an, ob das Senden der I-PDU erfolgreich war oder fehlschlug [SWS_Dlt_00756].

Nebenläufigkeit und Fehlerbehandlung

Die Spezifikation weist Dlt_TpTxConfirmation als synchron und reentrant (Reentrant) aus [SWS_Dlt_00756]. Spezifische DET- oder DEM-Fehlercodes sind für diesen Service nicht definiert; die Fehlerbehandlung bezüglich des Sendevorgangs stützt sich auf die Auswertung des Parameters result [SWS_Dlt_00756]. Der Aufruf dürfte im Systemkontext typischerweise durch eine unterlagerte Transportschicht nach Abschluss der PDU-Übertragung initiiert werden. Frage Q-0e5ab7c285316701 (offen)

Verwendung und Semantik

Die synchrone und reentrante Funktion Dlt_CopyTxData dient dem Abrufen von Sendedaten eines I-PDU-Segments (N-PDU) aus dem Dlt-Modul [SWS_Dlt_00516]. Über id wird die zu sendende I-PDU spezifiziert, während info den Zielpuffer (SduDataPtr) sowie die gewünschte Bytelänge (SduLength) bereitstellt [SWS_Dlt_00516]. Eine Übergabe von SduLength = 0 (bei der SduDataPtr als NULL_PTR übergeben werden darf) erlaubt es, reine Statusänderungen über retry zu übermitteln oder die verbleibende Datenmenge im Sendepuffer abzufragen [SWS_Dlt_00516]. Über den Ausgabeparameter availableDataPtr meldet die Funktion die noch verfügbare Datenmenge im Tx-Puffer zurück, was beispielsweise TP-Modulen mit dynamischer Nutzdatenlänge (wie FrIsoTp) die Dimensionierung nachfolgender Segmente ermöglicht [SWS_Dlt_00516].

Bestätigung und Fehlerbehebung

Über den Zeiger retry wird die Quittierung oder wiederholte Übertragung gesteuert [SWS_Dlt_00516]:

• Ist retry ein NULL_PTR, dürfen die kopierten Daten unmittelbar nach dem Kopiervorgang aus dem Puffer verworfen werden [SWS_Dlt_00516].
• Zeigt TpDataState den Wert TP_CONFPENDING, müssen zuvor kopierte Daten für eine eventuelle Fehlerbehebung im Puffer verbleiben [SWS_Dlt_00516].
• Bei TP_DATACONF gelten alle vor dem Aufruf übertragenen Daten als bestätigt und können freigegeben werden [SWS_Dlt_00516].
• Bei TP_DATARETRY setzt das Modul das Kopieren ab dem in TxTpDataCnt übergebenen Byte-Offset erneut an [SWS_Dlt_00516].

Rückgabewerte und Randbedingungen

Das Ergebnis der Anforderung wird als BufReq_ReturnType gemeldet [SWS_Dlt_00516]:

• BUFREQ_OK: Daten wurden vollständig wie gefordert in den Zielpuffer kopiert [SWS_Dlt_00516].
• BUFREQ_E_BUSY: Die geforderte Datenmenge ist nicht verfügbar; es wurden keine Daten kopiert, ein späterer Neuversuch ist zulässig [SWS_Dlt_00516].
• BUFREQ_E_NOT_OK: Anfrage fehlgeschlagen; es wurden keine Daten kopiert [SWS_Dlt_00516].

Die Schnittstelle ist über Dlt.h verfügbar und reentrant ausgelegt [SWS_Dlt_00516]. Der Aufrufkontext dürfte typischerweise in einem unterlagerten Transportprotokoll-Modul während der segmentierten Übertragung liegen. Frage Q-a81c439e73e0acc0 (offen)

Die synchrone und reentrante Funktion Dlt_StartReception wird zu Beginn des Empfangs einer N-SDU aufgerufen, welche als Einzelframe (SF) oder fragmentiert über mehrere N-PDUs empfangen werden kann [SWS_Dlt_91006]. Sie dient dazu, die Transportverbindung im Dlt-Modul zu initiieren und den verfügbaren Empfangspuffer bereitzustellen [SWS_Dlt_91006].

Über den Parameter id wird die empfangene I-PDU identifiziert, während info Nutzdaten und Metadaten des ersten Rahmens übermittelt oder auf NULL_PTR gesetzt ist, falls weder Daten noch Metadaten vorliegen [SWS_Dlt_91006]. Über TpSduLength wird die Gesamtlänge der N-SDU übergeben; wird die Funktion mit einer Länge von 0 aufgerufen, liefert sie die aktuell maximal verfügbare Puffergröße über bufferSizePtr zurück [SWS_Dlt_91006]. Das Transportprotokoll nutzt den Wert aus bufferSizePtr zur Berechnung der Block Size (BS) [SWS_Dlt_91006].

Wird die Verbindung akzeptiert, liefert die Funktion BUFREQ_OK; steht nicht genügend Puffer für die angeforderte Größe bereit, signalisiert bufferSizePtr eine Puffergröße von 0 zur Fortführung des Empfangs [SWS_Dlt_91006]. Bei Ablehnung der Verbindung bricht BUFREQ_E_NOT_OK den Empfang ab, und bei unzureichendem Gesamtspeicher wird BUFREQ_E_OVFL gemeldet; in beiden Fehlerfällen bleibt bufferSizePtr unverändert [SWS_Dlt_91006].

Die Funktion Dlt_TpRxIndication dient als synchrone Empfangsanzeige, nachdem eine I-PDU über die TP-API empfangen wurde [SWS_Dlt_91007]. Sie ist in der Header-Datei Dlt.h deklariert und besitzt die Service-ID 0x45 [SWS_Dlt_91007].

Verwendung und Parameter

Die Übergabe an das DLT-Modul erfolgt über zwei Eingabeparameter, wobei die Funktion keinen Rückgabewert liefert [SWS_Dlt_91007]:

• id (Typ PduIdType): Kennzeichnet die Identifikation der empfangenen I-PDU [SWS_Dlt_91007].
• result (Typ Std_ReturnType): Gibt das Resultat des Empfangs an und zeigt, ob die Übertragung erfolgreich war [SWS_Dlt_91007].

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als synchron und reentrant definiert [SWS_Dlt_91007]. Es existieren weder Ein-/Ausgangs- noch reine Ausgangsparameter [SWS_Dlt_91007].

Fehlerbehandlung und Zusammenspiel

Das Ergebnis des Transports wird dem DLT-Modul ausschließlich über das Argument result signalisiert; spezifische Fehlercodes, DET- oder DEM-Meldungen sind nicht spezifiziert [SWS_Dlt_91007].

Interpretation: Der Aufruf dürfte durch eine unterlagerte Transportprotokoll-Komponente erfolgen, sobald eine DLT-Nachricht vollständig eingetroffen ist oder die Übertragung abbricht [SWS_Dlt_91007]. Frage Q-7d9c8564a2404acf (offen)

Verwendung und Semantik

Die synchrone Funktion Dlt_CopyRxData wird aufgerufen, um empfangene Daten eines I-PDU-Segments (N-PDU) an die obere Schicht zu übergeben [SWS_Dlt_91008]. Jeder Aufruf stellt den jeweils nächsten Teil der I-PDU-Daten bereit, wobei die verbleibende Puffergröße an die über bufferSizePtr referenzierte Speicherstelle geschrieben wird [SWS_Dlt_91008]. Die Deklaration ist über den Header Dlt.h verfügbar [SWS_Dlt_91008].

Parameter und Pufferabfrage

Über den Eingabeparameter id wird die empfangene I-PDU identifiziert [SWS_Dlt_91008]. Der Zeiger info stellt über SduDataPtr den Quellpuffer sowie über SduLength die Anzahl der zu kopierenden Bytes bereit [SWS_Dlt_91008]. Wird SduLength mit dem Wert 0 übergeben, dient der Aufruf der reinen Abfrage des aktuell im oberen Modul verfügbaren Puffers; in diesem Fall darf SduDataPtr ein NULL_PTR sein [SWS_Dlt_91008]. Der Ausgabeparameter bufferSizePtr gibt die nach dem Kopiervorgang noch freie Empfangspuffergröße zurück [SWS_Dlt_91008].

Nebenläufigkeit und Rückgabewerte

Die Funktion ist reentrant ausgelegt und besitzt die Service-ID 0x44 [SWS_Dlt_91008]. Der Rückgabewert vom Typ BufReq_ReturnType signalisiert das Ergebnis des Kopiervorgangs: Bei erfolgreicher Datenübernahme liefert der Dienst BUFREQ_OK zurück, während im Fehlerfall BUFREQ_E_NOT_OK gemeldet wird [SWS_Dlt_91008].

Verwendung und Aufrufkontext

Die Funktion Dlt_TxFunction ist gemäß der Spezifikation [SWS_Dlt_91005] als Service mit der Service-ID 0x80 definiert und über den Header SchM_Dlt.h verfügbar. Ihre Schnittstellensignatur lautet void Dlt_TxFunction (void) [SWS_Dlt_91005]. Die Deklaration in SchM_Dlt.h deutet als Interpretation darauf hin, dass der Aufruf durch den BSW-Scheduler im Kontext einer zyklischen Task erfolgt und nicht direkt durch Anwendungs-Software-Components aufgerufen werden sollte.

Parameter und Rückgabewerte

Gemäß [SWS_Dlt_91005] nimmt die Funktion keine Übergabeparameter entgegen und liefert keinen Rückgabewert (void). Dem Namen nach dürfte die Funktion für das zyklische Abarbeiten und Übertragen anstehender Dlt-Sendenachrichten zuständig sein. Frage (offen) Da keine Rückgabewerte spezifiziert sind, erfolgt die Fehlerbehandlung vermutlich rein modul- bzw. zustandsintern.

Einschränkungen

Da der Payload keine Angaben zu Reentranz oder speziellen Entwicklungsfehlern enthält, sind Aufrufintervalle und Task-Zuordnungen über die Schedule-Manager-Konfiguration abzustimmen. Weitere Fehlercodes oder DET-Einträge sind in [SWS_Dlt_91005] nicht ausgewiesen.