AUTOSAR COM

Verwendung und Semantik

Die Funktion Com_Init initialisiert die internen und externen Schnittstellen sowie Variablen der AUTOSAR-COM-Schicht für die nachfolgende Verarbeitung ([SWS_Com_00432]). Der Aufruf erfolgt synchron und ist nicht reentrant (Non Reentrant) ([SWS_Com_00432]). Als Übergabeparameter dient config als Zeiger auf die Konfigurationsdaten des COM-Moduls (const Com_ConfigType* config); ein Rückgabewert existiert nicht ([SWS_Com_00432]). In Multi-Partition-Konfigurationen, in denen Hauptfunktionen des COM-Moduls mehreren Partitionen zugewiesen sind, kann COM je Partition eine eigene Initialisierungsfunktion bereitstellen ([SWS_Com_00432]).

Reihenfolgebedingungen und Fehlerbehandlung

Die Initialisierung über Com_Init ist die funktionale Voraussetzung für die reguläre Nutzung der COM-Schnittstellen: Wird ein API-Dienst vor Com_Init oder nach einem Aufruf von Com_DeInit aufgerufen, wird der Fehlercode COM_E_UNINIT (0x02) erzeugt ([SWS_Com_00804]). Ausgenommen von dieser Fehlerprüfung sind ausschließlich die Aufrufe von Com_GetStatus, Com_GetVersionInfo, Com_MainFunctionRx, Com_MainFunctionTx und Com_MainFunctionRouteSignals ([SWS_Com_00804]).

Zusammenspiel bei der PDU- und Signalinitialisierung

Nach Ausführung von Com_Init bleibt die eigentliche Inter-ECU-Kommunikation zunächst weiterhin deaktiviert ([SWS_Com_00432]). Interpretation: Für den regulären Sende- und Empfangsbetrieb dürfte daher eine nachgelagerte Aktivierung der jeweiligen I-PDU-Gruppen erforderlich sein. Frage Q-8407f9a6281c3764 (offen) Für bestimmte Datenstrukturen nimmt Com_Init jedoch bereits direkte Initialisierungen vor:

• Ist eine I-PDU keiner I-PDU-Gruppe zugewiesen, startet COM diese I-PDU bereits innerhalb von Com_Init so, als wäre sie über Com_IpduGroupStart mit gesetztem Initialisierungsparameter gestartet worden ([SWS_Com_00840]).
• Für Signalgruppen mit konfiguriertem Array-Zugriff (ComSignalGroupArrayAccess) initialisiert Com_Init den zugehörigen Pufferbereich der I-PDU anhand der Initialwerte (ComSignalInitValue) aller enthaltenen Gruppensignale ([SWS_Com_00850]).

Verwendung und Aufrufkontext

Die synchrone Funktion [SWS_Com_00130] (Interpretation: im Payload als 'Init' geführt, spezifiziert jedoch die Signatur void Com_DeInit(void)) beendet die Inter-ECU-Kommunikation und versetzt das AUTOSAR COM-Modul in den uninitialisierten Zustand ([SWS_Com_00130]). Frage Q-3e91d7d0a140cee0 (offen) Der Dienst besitzt die Service-ID 0x02, erfordert keine Übergabeparameter, liefert keinen Rückgabewert und wird über die Header-Datei Com.h bereitgestellt ([SWS_Com_00130]).

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Aufrufkontexts ist die Funktion als nicht reentrant (Non Reentrant) definiert ([SWS_Com_00130]). Ein paralleler oder mehrfacher Aufruf ohne vorherige Neuinitialisierung ist daher unzulässig.

Zusammenspiel und Lebenszyklus

Durch die Deinitialisierung werden sämtliche zuvor gestarteten I-PDU-Gruppen gestoppt ([SWS_Com_00130]). Für eine spätere Wiederaufnahme der Kommunikation gelten folgende Reihenfolgebedingungen:

• Das Modul muss über den synchronen, nicht reentranten Dienst Com_Init unter Übergabe des Konfigurationszeigers config neu initialisiert werden ([SWS_Com_00432]).
• Da die Inter-ECU-Kommunikation nach dem Aufruf von Com_Init weiterhin deaktiviert bleibt ([SWS_Com_00432]), müssen die benötigten I-PDU-Gruppen im Anschluss erneut explizit gestartet werden ([SWS_Com_00130]).

Die synchrone Funktion Com_IpduGroupStart (Service-ID 0x03, Header Com.h) dient dem Starten einer vorkonfigurierten I-PDU-Gruppe [SWS_Com_91001]. Nach dem Aufruf wird die Übertragung der zugehörigen I-PDUs aktiviert; beispielsweise werden zyklische I-PDUs fortan zyklisch versendet [SWS_Com_91001].

Verwendung und Parameter

Die Funktion besitzt keinen Rückgabewert und nimmt zwei Eingangsparameter entgegen [SWS_Com_91001]:

• IpduGroupId: Eindeutige Kennung der zu startenden vorkonfigurierten I-PDU-Gruppe [SWS_Com_91001].
• initialize: Ein boolesches Flag zur Anforderung der Dateninitialisierung der I-PDUs dieser Gruppe vor dem Start [SWS_Com_91001].

Ist initialize auf true gesetzt, müssen sämtliche I-PDUs der Gruppe vor dem Start (re-)initialisiert werden [SWS_Com_91001]. Die I-PDUs verhalten sich daraufhin wie unmittelbar nach einem Start-up des COM-Moduls [SWS_Com_91001]. Dies schließt insbesondere die Reinitialisierung des bisherigen Werts (old_value) von Filterobjekten sowie der Schattenpuffer für Signalgruppen ein [SWS_Com_91001].

Nebenläufigkeit und Einschränkungen

Bezüglich der Nebenläufigkeit ist Com_IpduGroupStart reentrant für unterschiedliche I-PDU-Gruppen, jedoch explizit nicht reentrant für dieselbe I-PDU-Gruppe [SWS_Com_91001].

Verwendung

Die Funktion Com_IpduGroupStop dient dem Stoppen einer vorkonfigurierten I-PDU-Gruppe im AUTOSAR-COM-Modul [SWS_Com_91002]. Die Deklaration ist über die Header-Datei Com.h verfügbar und besitzt die Service-ID 0x04 [SWS_Com_91002].

• Aufrufsyntax: void Com_IpduGroupStop (Com_IpduGroupIdType IpduGroupId) [SWS_Com_91002].
• Parameter: Als einziger Parameter wird der Eingangsparameter IpduGroupId vom Typ Com_IpduGroupIdType übergeben, welcher die Kennung der anzuhaltenden I-PDU-Gruppe festlegt [SWS_Com_91002]. Zusätzliche Ein-/Ausgangs- (inout) oder Ausgangsparameter (out) existieren nicht [SWS_Com_91002].
• Rückgabewert: Die Schnittstelle liefert keinen Rückgabewert (void) [SWS_Com_91002].
• Ausführungsverhalten: Der Aufruf wird synchron verarbeitet [SWS_Com_91002]. Nach dem Aufruf von Com_IpduGroupStop wird die Kommunikation der betroffenen Gruppe gestoppt; dies führt beispielsweise dazu, dass zyklische I-PDUs der Gruppe nicht mehr ausgesendet werden [SWS_Com_91002].

Nebenläufigkeit und Einschränkungen

In Bezug auf Nebenläufigkeit und Reentranz ist festgelegt, dass Com_IpduGroupStop für unterschiedliche I-PDU-Gruppen reentrant ist, jedoch für dieselbe I-PDU-Gruppe nicht reentrant ausgeführt werden darf [SWS_Com_91002]. Wird die Funktion in Multitasking- oder Multicore-Umgebungen aufgerufen, muss die rufende Software sicherstellen, dass konkurrierende Aufrufe für ein und dieselbe Gruppen-ID ausgeschlossen sind.

Die synchrone Funktion Com_EnableReceptionDM dient dazu, die Empfangsfristenüberwachung (Reception Deadline Monitoring) für alle I-PDUs innerhalb einer vorgegebenen I-PDU-Gruppe zu aktivieren [SWS_Com_91004].

Verwendung und Aufrufkontext: Die Funktion ist über die Header-Datei Com.h deklariert und besitzt die Service-ID 0x06 [SWS_Com_91004]. Als einzigen Übergabeparameter erwartet die Signatur void Com_EnableReceptionDM (Com_IpduGroupIdType IpduGroupId) den Eingabeparameter IpduGroupId vom Typ Com_IpduGroupIdType, welcher die Kennung der I-PDU-Gruppe darstellt, für deren enthaltene I-PDUs die Fristenüberwachung eingeschaltet werden soll [SWS_Com_91004]. Die Ausführung erfolgt synchron [SWS_Com_91004]. Es existieren weder Ein-/Ausgabeparameter noch Ausgabeparameter, und es wird kein Rückgabewert geliefert (Rückgabetyp void) [SWS_Com_91004].

Nebenläufigkeit und Einschränkungen: In Bezug auf die Nebenläufigkeit ist Com_EnableReceptionDM reentrant für unterschiedliche I-PDU-Gruppen, jedoch nicht reentrant für dieselbe I-PDU-Gruppe [SWS_Com_91004]. Konkurrierende Aufrufe für dieselbe Gruppen-ID sind daher nicht zulässig und müssen im Aufrufkontext vermieden werden [SWS_Com_91004].

Die synchrone Funktion Com_DisableReceptionDM deaktiviert die Empfangs-Deadline-Überwachung (Reception Deadline Monitoring) für alle I-PDUs innerhalb der übergebenen I-PDU-Gruppe [SWS_Com_91003].

Verwendung

Der Aufruf erfolgt über die Schnittstelle void Com_DisableReceptionDM(Com_IpduGroupIdType IpduGroupId) mit der Kennung der betroffenen I-PDU-Gruppe als Eingangsparameter IpduGroupId [SWS_Com_91003]. Die Funktion besitzt weder Ein-/Ausgangs- noch Ausgangsparameter und liefert keinen Rückgabewert (void) [SWS_Com_91003]. Deklariert ist der Dienst mit der Service-ID 0x05 in der Header-Datei Com.h [SWS_Com_91003].

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Nebenläufigkeitsverhaltens ist der Dienst reentrant für unterschiedliche I-PDU-Gruppen, darf jedoch für dieselbe I-PDU-Gruppe nicht nebenläufig (non-reentrant) aufgerufen werden [SWS_Com_91003].

Die Funktion Com_SendSignal dient der Aktualisierung eines durch SignalId identifizierten Signalobjekts mit den Daten, auf die der Zeiger SignalDataPtr verweist [SWS_Com_00197]. Der Aufruf wird asynchron abgewickelt [SWS_Com_00197].

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert einen Status vom Typ uint8 zurück [SWS_Com_00197]:

• E_OK: Der Service wurde akzeptiert [SWS_Com_00197].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Aufruf schlug aufgrund eines Entwicklungsfehlers fehl [SWS_Com_00197].
• COM_BUSY: Tritt auf, wenn der TP-Puffer für die Verarbeitung großer Datentypen gesperrt ist [SWS_Com_00197].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Reentranz ist Com_SendSignal für dasselbe Signal nicht reentrant, darf jedoch für unterschiedliche Signale nebenläufig aufgerufen werden [SWS_Com_00197]. Die Schnittstelle wird über den Header Com.h bereitgestellt [SWS_Com_00197].

Zusammenspiel und Konfiguration

Ist für eine Signalgruppe die Konfiguration ComSignalGroupArrayAccess definiert, wird der Aufruf von Com_SendSignal für die Gruppensignale dieser Signalgruppe nicht unterstützt [SWS_Com_00843].

Die Classic-AUTOSAR-Funktion Com_SendDynSignal dient der Aktualisierung eines Signalobjekts mit dynamischer Länge anhand der übergebenen Nutzdaten ([SWS_Com_00627]). Der Dienst besitzt die Service-ID 0x21 und arbeitet asynchron ([SWS_Com_00627]). Als Eingangsparameter erwartet die Schnittstelle die Kennung des Zielsignals (SignalId), einen Zeiger auf die zu übertragenden Signal-Nutzdaten (SignalDataPtr) sowie die aktuelle Länge des dynamischen Signals (Length); Ausgangsparameter sind nicht vorhanden ([SWS_Com_00627]).

Der Rückgabewert vom Typ uint8 meldet das Ergebnis der Auftragsannahme ([SWS_Com_00627]):

• E_OK: Der Dienstaufruf wurde erfolgreich akzeptiert ([SWS_Com_00627]).
• E_NOT_OK: Der Parameter Length übersteigt die für dieses Signal konfigurierte Maximallänge ComSignalLength ([SWS_Com_00627]).
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe ist gestoppt oder der Dienst schlug infolge eines Entwicklungsfehlers fehl ([SWS_Com_00627]).
• COM_BUSY: Der TP-Puffer ist gesperrt ([SWS_Com_00627]).

Bezüglich der Nebenläufigkeit ist Com_SendDynSignal reentrant für unterschiedliche Signale, jedoch nicht reentrant für dasselbe Signal ([SWS_Com_00627]). Die Funktionsdeklaration ist über den Header Com.h verfügbar ([SWS_Com_00627]).

Die synchrone Funktion Com_ReceiveSignal kopiert die Daten des über SignalId spezifizierten Signals an die über den Zeiger SignalDataPtr bereitgestellte Speicheradresse ([SWS_Com_00198]).

Verwendung und Semantik

Der Aufruf verarbeitet die Signalübergabe synchron und nimmt als Eingabeparameter die Kennung SignalId (vom Typ Com_SignalIdType) sowie als Ausgabeparameter den Zeiger SignalDataPtr (void*) auf den Zielpuffer entgegen ([SWS_Com_00198]). Die Schnittstelle ist über den Header Com.h verfügbar ([SWS_Com_00198]).

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert vom Typ uint8 signalisiert das Ergebnis der Funktionsausführung ([SWS_Com_00198]):

• E_OK: Der Dienst wurde erfolgreich akzeptiert und ausgeführt ([SWS_Com_00198]).
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Dienst schlug infolge eines Entwicklungsfehlers fehl ([SWS_Com_00198]).
• COM_BUSY: Tritt auf, falls der TP-Puffer für die Verarbeitung großer Datentypen gesperrt ist ([SWS_Com_00198]).

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Reentranz ist Com_ReceiveSignal nicht reentrant für dasselbe Signal, jedoch reentrant für unterschiedliche Signale ([SWS_Com_00198]). Bei parallelen Zugriffen auf identische Signal-IDs müssen Aufrufer folglich für eine geeignete Synchronisation sorgen.

Zudem besteht eine wesentliche Konfigurationseinschränkung: Falls für eine Signalgruppe der array-basierte Zugriff ComSignalGroupArrayAccess konfiguriert ist, wird der Aufruf von Com_ReceiveSignal für die enthaltenen Gruppensignale dieser Signalgruppe nicht unterstützt ([SWS_Com_00843]).

Verwendung und Semantik

Die synchrone Funktion Com_ReceiveDynSignal dient dem Empfang eines Signals mit dynamischer Länge anhand seiner SignalId [SWS_Com_00690]. Die empfangenen Signaldaten werden an die Speicherstelle kopiert, auf die SignalDataPtr zeigt [SWS_Com_00690]. Über den In-Out-Parameter Length übergibt der Aufrufer als Eingabewert die maximal aufnehmbare Länge; nach erfolgreichem Kopiervorgang wird dort die tatsächliche Länge des empfangenen dynamischen Signals abgelegt [SWS_Com_00690].

Rückgabewerte und Fehlerbehandlung

Die Funktion gibt einen Statuswert vom Typ uint8 zurück [SWS_Com_00690]:

• E_OK: Der Dienstaufruf wurde akzeptiert und die Daten wurden erfolgreich kopiert [SWS_Com_00690].
• E_NOT_OK: Der bereitgestellte Puffer ist zu klein, da der Eingabewert von Length kleiner ist als die tatsächliche Länge des empfangenen Signals [SWS_Com_00690].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Dienst schlug infolge eines Entwicklungsfehlers fehl [SWS_Com_00690].
• COM_BUSY: Der TP-Puffer ist derzeit gesperrt [SWS_Com_00690].

Nebenläufigkeit und Integration

Bezüglich der Reentranz ist Com_ReceiveDynSignal für dasselbe Signal nicht reentrant, für unterschiedliche Signale jedoch reentrant aufrufbar [SWS_Com_00690]. Die Deklaration ist über Com.h verfügbar [SWS_Com_00690].

Die asynchrone Funktion Com_SendSignalGroup dient dazu, den Inhalt des zugeordneten Shadow-Buffers in die zugehörige I-PDU zu kopieren [SWS_Com_00200]. Als Eingabeparameter nimmt sie die Kennung SignalGroupId der zu übertragenden Signalgruppe entgegen [SWS_Com_00200].

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert signalisiert den Ausführungsstatus des Dienstes [SWS_Com_00200]:

• E_OK: Der Dienstaufruf wurde erfolgreich akzeptiert [SWS_Com_00200].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Dienst schlug infolge eines Entwicklungsfehlers fehl [SWS_Com_00200].
• COM_BUSY: Der TP-Puffer ist für die Übertragung großer Datentypen temporär gesperrt [SWS_Com_00200].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist der Aufruf nicht reentrant für dasselbe Gruppensignal, jedoch reentrant für verschiedene Gruppensignale [SWS_Com_00200]. Interpretation: Die Einschränkung dürfte sich auf gleichzeitige Zugriffe auf dieselbe Signalgruppe beziehen. Frage Q-2f3a6da092b51794 (offen) Zudem wird der Aufruf von Com_SendSignalGroup für eine Signalgruppe nicht unterstützt, falls für diese ComSignalGroupArrayAccess konfiguriert wurde [SWS_Com_00843].

Zusammenspiel

Das AUTOSAR-COM-Modul behandelt einen Aufruf von Com_SendSignalGroupArray gleichwertig zu Com_SendSignalGroup bezüglich der Übertragungseigenschaften, der Auswahl des I-PDU-Übertragungsmodus sowie des Signalflusses [SWS_Com_00847].

Verwendung

Die synchrone Funktion Com_ReceiveSignalGroup dient dem Empfang von Signalgruppen. Sie kopiert die Daten der empfangenen Signalgruppe aus der entsprechenden I-PDU in den zugeordneten Schattenpuffer (Shadow Buffer) [SWS_Com_00201]. Als Eingabeparameter erwartet die Funktion die Kennung der Signalgruppe SignalGroupId vom Typ Com_SignalGroupIdType [SWS_Com_00201]. Deklariert ist der Dienst in der Header-Datei Com.h [SWS_Com_00201].

Fehlerbehandlung und Rückgabewerte

Der Dienst liefert einen Statuswert vom Typ uint8 zurück, der über den Erfolg oder die Fehlerursache Auskunft gibt [SWS_Com_00201]:

• E_OK: Der Dienst wurde erfolgreich akzeptiert und die Signalgruppe kopiert [SWS_Com_00201].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Aufruf schlug aufgrund eines Entwicklungsfehlers fehl [SWS_Com_00201].
• COM_BUSY: Der Dienst meldet diesen Zustand, falls der TP-Puffer für die Handhabung großer Datentypen gesperrt ist [SWS_Com_00201].

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Nebenläufigkeitsverhaltens ist Com_ReceiveSignalGroup nicht reentrant für dieselbe Signalgruppe, jedoch reentrant für unterschiedliche Signalgruppen ausgeführt [SWS_Com_00201].

Zudem besteht eine wesentliche Einschränkung beim Zusammenspiel mit dem Array-Zugriff: Falls für eine Signalgruppe die Konfiguration ComSignalGroupArrayAccess (ECUC_Com_10003) definiert wurde, wird der Aufruf von Com_ReceiveSignalGroup für diese Signalgruppe spezifikationsgemäß nicht unterstützt [SWS_Com_00843].

Die asynchrone Funktion Com_SendSignalGroupArray kopiert die Daten einer Signalgruppe über den Zeiger SignalGroupArrayPtr direkt in die zugeordnete I-PDU [SWS_Com_00851]. Die übergebenen Daten müssen dabei exakt der Array-Darstellung der jeweiligen Signalgruppe entsprechen [SWS_Com_00851], [SWS_Com_00852].

Als Eingangsparameter werden die Kennung der Signalgruppe (SignalGroupId) sowie die Referenz auf das Signalgruppen-Array (SignalGroupArrayPtr) übergeben [SWS_Com_00851]. Der Dienst liefert folgende Rückgabewerte [SWS_Com_00851]:

• E_OK: Der Dienstaufruf wurde erfolgreich akzeptiert.
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Aufruf schlug durch einen Entwicklungsfehler fehl.
• COM_BUSY: Der Transportprotokoll-Puffer (TP-Buffer) ist für die Verarbeitung großer Datentypen gesperrt.

Hinsichtlich der Nebenläufigkeit ist die Funktion für dieselbe Signalgruppe nicht reentrant, darf jedoch für unterschiedliche Signalgruppen reentrant aufgerufen werden [SWS_Com_00851]. Der Aufruf steht nur dann zur Verfügung, wenn der Konfigurationsschalter ComEnableSignalGroupArrayApi aktiviert ist [SWS_Com_00853].

Bezüglich der Übertragungseigenschaften von Signalgruppen, der Auswahl des I-PDU-Übertragungsmodus und des Signalflusses wird Com_SendSignalGroupArray vom AUTOSAR-COM-Modul vollständig analog zu Com_SendSignalGroup behandelt [SWS_Com_00847].

Verwendung und Konfiguration

Die synchrone Funktion Com_ReceiveSignalGroupArray kopiert die empfangene Signalgruppe als Byte-Array-Repräsentation aus der I-PDU in den Speicherbereich, auf den SignalGroupArrayPtr verweist [SWS_Com_00854], [SWS_Com_00855]. Die Funktion steht ausschließlich dann zur Verfügung, wenn der Konfigurationsschalter ComEnableSignalGroupArrayApi aktiviert ist [SWS_Com_00856]. Sie unterstützt Empfangsfilterung und Transmission Mode Selection mit den Filtern ALWAYS, NEVER, MASKED_NEW_EQUALS_X, MASKED_NEW_DIFFERS_X, MASKED_NEW_DIFFERS_MASKED_OLD und ONE_EVERY_N [SWS_Com_00848].

Datenkopie und Fehlerbehandlung

Beim Aufruf wird die SignalGroupId sowie ein Zeiger auf das Zielarray übergeben, an dessen Position das AUTOSAR-COM-Modul die Daten der I-PDU kopiert [SWS_Com_00849]. Selbst wenn die I-PDU-Gruppe gestoppt ist und der Dienst COM_SERVICE_NOT_AVAILABLE zurückgibt, kopiert das Modul stets die zuletzt bekannten Daten oder die Initialwerte ComSignalInitValues, falls zuvor noch keine Daten geschrieben wurden [SWS_Com_00857].

Rückgabewerte und Nebenläufigkeit

Mögliche Rückgabewerte des Dienstes sind [SWS_Com_00854]:

• E_OK: Der Dienst wurde erfolgreich akzeptiert.
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe ist gestoppt oder der Dienst schlug wegen eines Entwicklungsfehlers fehl.
• COM_BUSY: Der TP-Puffer ist für die Verarbeitung großer Datentypen gesperrt.

Bezüglich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche Signalgruppen, jedoch nicht reentrant für dieselbe Signalgruppe [SWS_Com_00854].

Die synchrone Funktion Com_ReceiveSignalWithMetaData dient dem Auslesen empfangener Signaldaten zusammen mit ihren Metadaten aus dem Kommunikationsmodul Com [SWS_Com_91005]. Beim Aufruf kopiert der Dienst die Daten des über die SignalId adressierten Signals an den Speicherort, auf den SignalDataPtr verweist, und legt die empfangenen Metadaten an der Position MetaDataPtr ab [SWS_Com_91005].

Parameter und Aufrufkontext

Die Schnittstelle ist über den Header Com.h verfügbar und wird über die Service-ID 0x49 identifiziert [SWS_Com_91005]. Die Parameterstruktur gliedert sich wie folgt:

• SignalId (in): Kennung des zu empfangenden Signals [SWS_Com_91005].
• SignalDataPtr (out): Zeiger auf den Speicherort zur Ablage der empfangenen Signaldaten [SWS_Com_91005].
• MetaDataPtr (out): Zeiger auf den Speicherbereich zur Aufnahme der Signal-Metadaten [SWS_Com_91005].

Die Funktion liefert einen Rückgabewert vom Typ uint8 zurück, für den im vorliegenden Standardabschnitt keine spezifischen Fehlerwerte dokumentiert sind [SWS_Com_91005].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Reentranz ist der Dienst reentrant für unterschiedliche Signale, jedoch nicht reentrant für dasselbe Signal [SWS_Com_91005]. Bei parallelen oder unterbrechenden Aufrufen mit identischer SignalId dürfte folglich eine externe Absicherung durch den Aufrufer erforderlich sein, um Datenkonsistenz zu gewährleisten. Frage Q-51cbdce3d4f59f24 (offen)

Verwendung und Semantik

Die Funktion Com_ReceiveDynSignalWithMetaData wird über die Header-Datei Com.h bereitgestellt und dient dem synchronen Empfang von Signalen mit dynamischer Länge einschließlich ihrer Metadaten [SWS_Com_91006]. Beim Aufruf kopiert der Dienst die Daten des über SignalId identifizierten Signals in den durch SignalDataPtr referenzierten Puffer [SWS_Com_91006]. Die empfangenen Metadaten werden am Zeiger MetaDataPtr abgelegt, während die tatsächliche Länge des empfangenen dynamischen Signals an die Position von Length geschrieben wird [SWS_Com_91006].

Rückgabewerte und Fehlerbehandlung

Der Dienst liefert einen Statuswert vom Typ uint8 zurück [SWS_Com_91006]:

• E_OK: Der Empfangsdienst wurde erfolgreich akzeptiert [SWS_Com_91006].
• E_NOT_OK: Tritt auf, wenn der übergebene Wert von Length kleiner ist als die tatsächliche Länge des empfangenen dynamischen Signals [SWS_Com_91006]. Interpretation: Der Aufrufer muss über Length vorab die Puffergröße bereitstellen, sodass der Parameter faktisch als kombinierte Ein- und Ausgabe fungiert. Frage Q-8ad420c74748f219 (offen)
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe ist gestoppt oder der Aufruf schlug aufgrund eines Entwicklungsfehlers fehl [SWS_Com_91006].
• COM_BUSY: Der TP-Puffer ist aktuell gesperrt [SWS_Com_91006].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche Signale, darf jedoch für dasselbe Signal nicht reentrant aufgerufen werden [SWS_Com_91006]. Parallele Aufrufe für dieselbe SignalId müssen daher auf Aufruferebene synchronisiert werden.

Die synchrone Funktion Com_ReceiveSignalGroupWithMetaData dient dem Empfang einer Signalgruppe einschließlich zugehöriger Metadaten über die Schnittstelle Com.h [SWS_Com_91007]. Sie übernimmt als Eingabeparameter die Kennung SignalGroupId und kopiert die empfangenen Daten der Signalgruppe aus der I-PDU in den lokalen Shadow-Buffer [SWS_Com_91007]. Gleichzeitig speichert der Dienst die empfangenen Metadaten an der über den Ausgabeparameter MetaDataPtr referenzierten Zieladresse ab [SWS_Com_91007].

Das Fehler- und Rückgabeverhalten umfasst drei Statuswerte: E_OK signalisiert die erfolgreiche Annahme des Dienstes [SWS_Com_91007]. Der Rückgabewert COM_SERVICE_NOT_AVAILABLE zeigt an, dass die zugehörige I-PDU-Gruppe gestoppt ist oder ein Entwicklungsfehler vorliegt [SWS_Com_91007]. Tritt der Fehlercode COM_BUSY auf, ist der TP-Puffer für die Verarbeitung großer Datentypen gesperrt [SWS_Com_91007]. Bezüglich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche Signalgruppen, aber nicht reentrant für dieselbe Signalgruppe [SWS_Com_91007]. Da die Spezifikation keine ISR-Einschränkungen nennt, dürfte der Aufruf synchron auf Task-Ebene durch die übergeordnete Softwarekomponente erfolgen. Frage Q-a23cf67bae724ae1 (offen)

Im Zusammenspiel erweitert die Funktion den Empfangspfad um Metadaten analog zu Com_ReceiveSignalWithMetaData für Einzelsignale [SWS_Com_91005]. Die bereitgestellten Metadaten korrespondieren mit den zuvor über Com_RxIndication an der Schnittstelle empfangenen PDU-Informationen [SWS_Com_00123]. Zur Signalisierung ungültiger Dateninhalte kann im Gesamtablauf zudem Com_InvalidateSignalGroup herangezogen werden [SWS_Com_00557].

Verwendung

Der synchrone Dienst Com_ReceiveSignalGroupArrayWithMetaData (Service-ID 0x4c, verfügbar über Com.h) kopiert die empfangene Signalgruppen-Array-Darstellung aus der I-PDU in den Speicherort, der über den Zeiger SignalGroupArrayPtr bereitgestellt wird [SWS_Com_91008]. Gleichzeitig werden die empfangenen Metadaten an die durch den Parameter MetaDataPtr angegebene Position geschrieben [SWS_Com_91008]. Die Funktion besitzt keinen Rückgabewert (void) [SWS_Com_91008].

Fehlerbehandlung

Die Spezifikation definiert für diesen Dienst keine Rückgabewerte und listet keine spezifischen Fehlercodes [SWS_Com_91008]. Interpretation: Etwaige Fehlerzustände bei Aufrufparametern dürften vermutlich intern abgefangen und über das Fehlerreporting des Moduls behandelt werden; konkrete DET- oder DEM-Meldungen gehen aus dem Spezifikationsauszug jedoch nicht hervor. Frage (offen)

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche Signalgruppen, jedoch nicht reentrant für dieselbe Signalgruppe [SWS_Com_91008]. Parallele Aufrufe mit identischer SignalGroupId müssen aufruferseitig unterbunden werden. Interpretation: Aufrufer dürften zudem verpflichtet sein, ausreichend dimensionierte Zielpuffer bereitzustellen, da die Schnittstelle keine Längenparameter mitführt. Frage (offen)

Zusammenspiel

Die Bereitstellung der Daten im PDU-Puffer setzt voraus, dass zuvor eine Empfangsanzeige über Com_RxIndication stattgefunden hat, welche auch die Metadaten an das COM-Modul liefert [SWS_Com_00123]. Die Funktion erweitert die Empfangsschnittstellen für Metadaten analog zu Com_ReceiveSignalWithMetaData für Einzelsignale [SWS_Com_91005] und unterscheidet sich von der regulären Signalabholung via Com_ReceiveSignal [SWS_Com_00198].

Die Funktion Com_SendSignalWithMetaData ([SWS_Com_91009]) dient dem asynchronen Aktualisieren eines durch SignalId spezifizierten Signalobjekts mit Nutzdaten über SignalDataPtr sowie zugehörigen Metadaten über MetaDataPtr. Der Dienst ist über den Header Com.h verfügbar.

• Aufruf und Nebenläufigkeit: Der Aufruf erfolgt asynchron ([SWS_Com_91009]). Die Funktion ist für unterschiedliche Signale reentrant, für denselben Signalbezeichner (SignalId) jedoch nicht reentrant ([SWS_Com_91009]).
• Rückgabewerte und Fehlerbehandlung: Die Funktion liefert einen Statuswert vom Typ uint8 zurück ([SWS_Com_91009]):
  • E_OK: Der Sendeauftrag wurde erfolgreich vom Modul akzeptiert ([SWS_Com_91009]).
  • COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe ist gestoppt oder der Aufruf schlug aufgrund eines Entwicklungsfehlers fehl ([SWS_Com_91009]).
  • COM_BUSY: Der TP-Puffer ist für die Verarbeitung großer Datentypen gesperrt ([SWS_Com_91009]).
• Zusammenspiel: Im Unterschied zum Basissendedienst Com_SendSignal ([SWS_Com_00197]) übergibt diese Funktion explizite Metadaten. Sie bildet das sendeseitige Gegenstück zum Empfangsdienst Com_ReceiveSignalWithMetaData ([SWS_Com_91005]) und ergänzt I-PDU-bezogene Metadaten-Dienste wie Com_TriggerIPDUSendWithMetaData ([SWS_Com_00858]).

Verwendung und Semantik

Die Funktion Com_SendDynSignalWithMetaData dient der asynchronen Aktualisierung eines über SignalId (Typ Com_SignalIdType) identifizierten Signalobjekts mit Signaldaten dynamischer Länge sowie den zugehörigen Metadaten [SWS_Com_91010]. Die zu übertragenden Nutzdaten werden über den Zeiger SignalDataPtr (Typ void*) referenziert, während MetaDataPtr (Typ uint8*) auf die Metadaten verweist [SWS_Com_91010]. Über den Parameter Length (Typ uint16) wird die tatsächliche Länge des zu versendenden dynamischen Signals übergeben [SWS_Com_91010].

Rückgabewerte und Fehlerbehandlung

Der Rückgabewert vom Typ uint8 signalisiert, ob der Dienst akzeptiert wurde oder welcher Fehler vorliegt [SWS_Com_91010]:

• E_OK: Der Dienstaufruf wurde erfolgreich zur Verarbeitung angenommen [SWS_Com_91010].
• E_NOT_OK: Die übergebene Length übersteigt die für dieses Signal konfigurierte ComSignalLength [SWS_Com_91010].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder der Aufruf schlug durch einen Entwicklungsfehler fehl [SWS_Com_91010].
• COM_BUSY: Der TP-Puffer ist derzeit gesperrt, weshalb das Signal nicht gesendet werden kann [SWS_Com_91010].

Nebenläufigkeit und Integration

Hinsichtlich der Nebenläufigkeit ist die Funktion für unterschiedliche Signale reentrant, für dasselbe Signal jedoch nicht reentrant [SWS_Com_91010]. Die Schnittstelle besitzt die Service-ID 0x4e und wird im Modul Com über die Header-Datei Com.h zur Verfügung gestellt [SWS_Com_91010].

Die Funktion Com_SendSignalGroupWithMetaData (im Datenmodell als Data bezeichnet) dient der asynchronen Übertragung einer Signalgruppe zusammen mit Metadaten an das Modul Com [SWS_Com_91011]. Beim Aufruf kopiert der Dienst den aktuellen Inhalt des zugeordneten Shadow-Buffers in das zugehörige I-PDU, wobei die Metadaten über den Zeiger MetaDataPtr bereitgestellt werden [SWS_Com_91011].

Die Übergabeparameter umfassen die Kennung der Signalgruppe (SignalGroupId) sowie den Zeiger auf die Metadaten (MetaDataPtr) [SWS_Com_91011]. Die Rückgabewerte melden das Ergebnis der Dienstanforderung:

• E_OK: Der Dienst wurde erfolgreich akzeptiert [SWS_Com_91011].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe wurde gestoppt oder die Ausführung schlug durch einen Entwicklungsfehler fehl [SWS_Com_91011].
• COM_BUSY: Der TP-Puffer ist für die Übertragung großer Datentypen gesperrt [SWS_Com_91011].

Bezüglich der Nebenläufigkeit ist der Aufruf für unterschiedliche Signale reentrant, jedoch nicht reentrant für dasselbe Gruppensignal; dies dürfte sich analog zum Parameter SignalGroupId auf die jeweilige Signalgruppe beziehen [SWS_Com_91011]. Frage Q-91171d77370ae50a (offen) Im Zusammenspiel mit dem Modul Com ergänzt der Dienst das Senden einzelner Signale wie Com_SendSignal [SWS_Com_00197] sowie das Invalidieren von Signalgruppen via Com_InvalidateSignalGroup [SWS_Com_00557]. Zudem korrespondiert er mit dem Empfangsdienst Com_ReceiveSignalWithMetaData [SWS_Com_91005] und dem PDU-basierten Sendeaufruf Com_TriggerIPDUSendWithMetaData [SWS_Com_00858].

Verwendung und Parameter

Die Funktion Com_SendSignalGroupArrayWithMetaData dient dem asynchronen Übertragen einer Signalgruppe mitsamt zugehöriger Metadaten [SWS_Com_91012]. Beim Aufruf kopiert der Dienst den Inhalt des übergebenen Zeigers SignalGroupArrayPtr direkt in die zugeordnete I-PDU [SWS_Com_91012]. Die bereitgestellten Daten müssen dabei zwingend der Array-Repräsentation der Signalgruppe entsprechen, welche über den Parameter SignalGroupId vom Typ Com_SignalGroupIdType identifiziert wird [SWS_Com_91012]. Zusätzliche Metadaten der Signalgruppe werden über den Zeiger MetaDataPtr an die Kommunikationsschicht übergeben [SWS_Com_91012].

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert einen Statuswert vom Typ uint8 zurück, der den Erfolg der Übergabe oder die jeweilige Fehlerursache anzeigt [SWS_Com_91012]:

• E_OK: Der Dienstaufruf wurde erfolgreich von der COM-Schicht akzeptiert [SWS_Com_91012].
• COM_SERVICE_NOT_AVAILABLE: Die zugehörige I-PDU-Gruppe ist gestoppt oder der Aufruf schlug aufgrund eines Entwicklungsfehlers fehl [SWS_Com_91012].
• COM_BUSY: Der Puffer des Transportprotokolls (TP-Buffer) ist für die Verarbeitung großer Datentypen gesperrt [SWS_Com_91012].

Nebenläufigkeit und Einschränkungen

Gemäß Spezifikation ist der Dienst als nicht reentrant (Non Reentrant) eingestuft, weshalb gleichzeitige oder unterbrechende Aufrufe unzulässig sind [SWS_Com_91012]. Die Schnittstelle besitzt die Service-ID 0x50 und wird über die Header-Datei Com.h bereitgestellt [SWS_Com_91012].

Die Funktion Com_InvalidateSignal dient der Ungültigkeitserklärung eines Signals im Kommunikationsmodul [SWS_Com_00203]. Sie setzt den Wert des übergebenen Signals auf den in der Konfiguration hinterlegten Ungültigkeitswert Com Signal Data Invalid Value [SWS_Com_00203]. Die Verarbeitung erfolgt asynchron [SWS_Com_00203]. Als einziger Übergabeparameter wird der Eingabeparameter SignalId zur Identifikation des Signals übergeben; Ein-/Ausgabe- oder Ausgabeparameter existieren nicht [SWS_Com_00203].

Als Rückgabewert liefert der Aufruf einen Status vom Typ uint8, der das Annahme- und Fehlerverhalten abbildet [SWS_Com_00203]:

• E_OK: Der Invalidation-Service wurde erfolgreich akzeptiert [SWS_Com_00203].
• COM_SERVICE_NOT_AVAILABLE: Der Dienst steht nicht zur Verfügung. Dies tritt auf, wenn die zugehörige I-PDU-Gruppe gestoppt ist, wenn für die angegebene SignalId kein Com Signal Data Invalid Value konfiguriert wurde oder wenn die Ausführung infolge eines Entwicklungsfehlers fehlschlägt [SWS_Com_00203].
• COM_BUSY: Der Dienst kann aktuell nicht ausgeführt werden, da der TP-Puffer gesperrt ist [SWS_Com_00203].

In Bezug auf die Nebenläufigkeit ist Com_InvalidateSignal nicht reentrant für dasselbe Signal, darf aber für unterschiedliche Signale parallel und reentrant ausgeführt werden [SWS_Com_00203]. Der Service ist unter der Service-ID 0x10 deklariert und über den Header Com.h verfügbar [SWS_Com_00203].

Die Funktion Com_InvalidateSignalGroup dient dazu, alle Gruppensignale der übergebenen Signalgruppe auf ihre jeweils konfigurierten ComSignalDataInvalidValue-Werte zu setzen und die Signalgruppe damit zu invalidieren [SWS_Com_00557].

Verwendung und Semantik

Als Eingangsparameter erwartet der Dienst die ID der zu invalidierenden Signalgruppe (SignalGroupId vom Typ Com_SignalGroupIdType) [SWS_Com_00557]. Der Aufruf wird asynchron verarbeitet und liefert einen Statuswert vom Typ uint8 zurück [SWS_Com_00557].

Rückgabewerte und Fehlerbehandlung

Folgende Rückgabewerte sind spezifiziert [SWS_Com_00557]:

• E_OK: Die Anforderung zur Invalidierung wurde erfolgreich akzeptiert.
• COM_SERVICE_NOT_AVAILABLE: Der Dienst steht nicht zur Verfügung, weil die zugehörige I-PDU-Gruppe gestoppt ist, für keines der Gruppensignale ein ComSignalDataInvalidValue konfiguriert wurde oder der Aufruf infolge eines Entwicklungsfehlers fehlschlägt.
• COM_BUSY: Der Puffer des Transportprotokolls (TP-Buffer) ist derzeit gesperrt.

Nebenläufigkeit und Reentranz

Die Funktion ist nicht reentrant für dieselbe Signalgruppe, darf jedoch für unterschiedliche Signalgruppen nebenläufig (reentrant) aufgerufen werden [SWS_Com_00557]. Die Deklaration ist über Com.h verfügbar [SWS_Com_00557].

Die synchrone Funktion Com_TriggerIPDUSend stößt die Übertragung der durch den Parameter PduId identifizierten I-PDU an [SWS_Com_00348]. Sie steht über den Header Com.h zur Verfügung [SWS_Com_00348].

Aufrufbedingungen und Rückgabewerte

Der Aufruf stößt das Senden nur dann an, wenn die betreffende I-PDU gestartet ist [SWS_Com_00861]. Dementsprechend differenziert der Rückgabewert vom Typ Std_ReturnType den Status der I-PDU [SWS_Com_00348]:

• E_OK: Die I-PDU wurde erfolgreich zur Übertragung angestoßen [SWS_Com_00348].
• E_NOT_OK: Die I-PDU befindet sich im gestoppten Zustand, sodass die Übertragung nicht angestoßen werden konnte [SWS_Com_00348].

Puffer- und Nebenläufigkeitsverhalten

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Com_00348]. Für große I-PDUs ist ein Pufferungsmechanismus vorgesehen: Wird eine große I-PDU über Com_TriggerIPDUSend angestoßen, während ihr Puffer gesperrt ist, speichert AUTOSAR COM die Sendeanforderung zwischen und überträgt die I-PDU erst, sobald der Puffer wieder verfügbar ist [SWS_Com_00867].

Die Funktion Com_TriggerIPDUSendWithMetaData dient dazu, die Übertragung einer I-PDU synchron anzustoßen und zuvor deren interne Metadaten im AUTOSAR COM-Modul zu aktualisieren [SWS_Com_00858]. Der Aufruf erwartet als Parameter PduId die Kennung der zu sendenden I-PDU sowie mit MetaData einen Zeiger auf die bereitzustellenden Metadaten [SWS_Com_00858]. Das COM-Modul kopiert die Daten ab der referenzierten Adresse unter Berücksichtigung der global konfigurierten Länge des Metadatentyps der I-PDU in seine interne Datenhaltung und stößt unmittelbar danach die Übertragung an [SWS_Com_00858].

Gemäß [SWS_Com_00862] darf das COM-Modul die Übertragung der I-PDU jedoch nur dann anstoßen, wenn sich die I-PDU im Zustand gestartet befindet. Ist die I-PDU hingegen gestoppt, unterbleibt das Auslösen der Übertragung.

Das Ergebnis der Ausführung wird über den Rückgabewert signalisiert:

• E_OK: Die Übertragung der I-PDU wurde erfolgreich ausgelöst [SWS_Com_00858].
• E_NOT_OK: Die I-PDU ist gestoppt; die Übertragung konnte nicht angestoßen werden [SWS_Com_00858].

Spezifische Fehlercodes für DET oder DEM sind für diesen Dienst im Payload nicht dokumentiert.

Hinsichtlich der Nebenläufigkeit ist die Schnittstelle als nicht reentrant (Non Reentrant) definiert [SWS_Com_00858], weshalb parallele Aufrufe ausgeschlossen bzw. synchronisiert werden müssen. Vermutlich liegt es in der Verantwortung des Aufrufers, für die Gültigkeit des Zeigers MetaData und eine ausreichende Puffergröße entsprechend der konfigurierten Metadatenlänge zu sorgen. Frage Q-66c6abae0bbde275 (offen)

Die synchrone Schnittstelle Com_SwitchIpduTxMode dient dem Umschalten des Übertragungsmodus einer I-PDU und ist im Header Com.h unter der Service-ID 0x27 spezifiziert [SWS_Com_00784]. Als Parameter werden die Kennung der betreffenden I-PDU (PduId) sowie der gewünschte Übertragungsmodus als Wahrheitswert (Mode) übergeben; ein Rückgabewert oder Ausgabeparameter ist nicht vorhanden [SWS_Com_00784]. Der Aufruf schaltet die Übertragungseigenschaften synchron und direkt während der Ausführung um [SWS_Com_00784].

Für die Wirksamkeit der Modusänderung definiert die Spezifikation zwei Fälle:

• Wechselt der Übertragungsmodus durch den Aufruf, so tritt die neue Betriebsart für die referenzierte I-PDU unverzüglich in Kraft [SWS_Com_00784], [SWS_Com_00239].
• War der angeforderte Übertragungsmodus für die betroffene I-PDU bereits aktiv, so bleibt der Aufruf vollständig wirkungslos [SWS_Com_00784].

Hinsichtlich des weiteren Sendeablaufs gilt für das Zusammenspiel mit dem zyklischen Versand: Wird der Übertragungsmodus einer I-PDU explizit über Com_SwitchIpduTxMode gesetzt, verzögert das AUTOSAR-COM-Modul die nachfolgenden zyklischen Sendungen dieser I-PDU um den Zeitversatz ComTxModeTimeOffset [SWS_Com_00881].

Bezüglich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche I-PDU-Instanzen ausgelegt [SWS_Com_00784]. Ein nebenläufiger oder paralleler Aufruf für dieselbe PduId ist hingegen als nicht reentrant definiert und muss vom Aufrufer unterbunden werden [SWS_Com_00784].

Die synchrone Funktion [SWS_Com_00001] dient dem synchronen Abruf und Kopieren von SDU-Daten einer zu übertragenden Sende-PDU (TxPduId) in den vom Aufrufer bereitgestellten Puffer. Der Aufrufer übergibt über den Ein- und Ausgangsparameter PduInfoPtr sowohl die Zieladresse SduDataPtr als auch die maximal verfügbare Pufferkapazität in SduLength. Sofern die SDU-Daten vollständig in den Puffer passen, werden sie kopiert, PduInfoPtr->SduLength wird auf die tatsächlich kopierte Byteanzahl aktualisiert und der Dienst schließt erfolgreich mit E_OK ab [SWS_Com_00001].

Fehlerbehandlung und Randbedingungen

Die Funktion bricht die Ausführung ab, kopiert keine Daten und liefert E_NOT_OK zurück, wenn eine der folgenden Bedingungen zutrifft:

• Die bereitgestellte Puffergröße in PduInfoPtr->SduLength ist kleiner als die tatsächliche PDU-Länge [SWS_Com_00001], [SWS_Com_00869]. In diesem Fall bleibt PduInfoPtr unverändert [SWS_Com_00001].
• Die entsprechende I-PDU befindet sich im Zustand gestoppt [SWS_Com_00884].

Im Fehlerfall (E_NOT_OK) darf der Aufrufer den Zeiger PduInfoPtr nicht auswerten oder weiterverwenden, da er auf ungültige Daten verweisen oder einen NULL-Zeiger darstellen kann [SWS_Com_00001].

Nebenläufigkeit

Hinsichtlich der Nebenläufigkeit ist die Schnittstelle für unterschiedliche PDU-IDs reentrant ausgelegt, darf jedoch für dieselbe TxPduId nicht nebenläufig aufgerufen werden [SWS_Com_00001].

Die Funktion Com_RxIndication dient der Signalisierung und Übergabe einer empfangenen PDU von einem unterlagerten Kommunikationsschnittstellenmodul an das AUTOSAR-COM-Modul [SWS_Com_00123]. Die Funktionsdeklaration wird über die Header-Datei Com.h bereitgestellt und besitzt die Service-ID 0x42 [SWS_Com_00123].

Der Aufruf erfolgt mit synchroner Semantik und liefert keinen Rückgabewert zurück (void) [SWS_Com_00123]. Die Schnittstelle definiert weder Ein-/Ausgangsparameter noch reine Ausgangsparameter, sondern ausschließlich zwei Eingangsparameter [SWS_Com_00123]:

• RxPduId (Datentyp PduIdType): Repräsentiert den eindeutigen Bezeichner der empfangenen PDU [SWS_Com_00123].
• PduInfoPtr (Zeiger auf konstanten PduInfoType): Verweist auf die Datenstruktur, welche die Länge der empfangenen PDU (SduLength), einen Zeiger auf den Puffer mit den PDU-Daten (SduDataPtr) sowie zugehörige Metadaten enthält [SWS_Com_00123].

Hinsichtlich des Nebenläufigkeitsverhaltens ist Com_RxIndication als reentrant für Aufrufe mit unterschiedlichen PDU-IDs definiert, jedoch ausdrücklich als nicht reentrant für dieselbe PDU-ID [SWS_Com_00123]. Interpretation: Aufrufende Module der unterlagerten Kommunikationsschnittstelle dürften daher verpflichtet sein, konkurrierende Aufrufe für identische PDU-IDs zu synchronisieren oder zu serialisieren, um Datenkonsistenz zu wahren. Frage Q-f3b6194f96c15091 (offen)

Die synchrone Service-Funktion Com_TpRxIndication wird aufgerufen, sobald eine I-PDU über das TP-API empfangen wurde [SWS_Com_00650]. Sie informiert das AUTOSAR-COM-Modul über den Abschluss und das Ergebnis des Empfangsvorgangs. Über den Parameter id wird die betroffene I-PDU identifiziert, während der Parameter result angibt, ob die Übertragung erfolgreich war oder fehlschlug [SWS_Com_00650]. Die Funktion besitzt keinen Rückgabewert und ist im Header Com.h mit der Service-ID 0x45 definiert [SWS_Com_00650]. Als Aufrufer dürfte vermutlich eine unterlagerte Transportschicht wie das PduR- oder ein TP-Modul fungieren. Frage Q-d7006169cd162db4 (offen)

Fehlerbehandlung

Wird Com_TpRxIndication mit dem Ergebniswert E_NOT_OK für den Parameter result aufgerufen, behandelt das COM-Modul alle Signale der empfangenen großen I-PDU exakt wie ungültig gewordene Signale [SWS_Com_00838]. Das Modul führt in diesem Fehlerfall sämtliche konfigurierten ComDataInvalidActions für alle enthaltenen Signale und Signalgruppen aus [SWS_Com_00838].

Nebenläufigkeit und Randbedingungen

Die Funktion ist als reentrant spezifiziert und arbeitet synchron [SWS_Com_00650]. Sie kann daher parallel für unterschiedliche I-PDUs aufgerufen werden, sollte jedoch im Kontext der aufrufenden Instanz ohne Verzögerung abgearbeitet werden.

Die synchrone Callback-Funktion Com_TxConfirmation wird über den Header Com.h deklariert und dient als zentrale Bestätigungsschnittstelle des AUTOSAR-COM-Moduls [SWS_Com_00124]. Ein unterlagertes Kommunikationsschnittstellenmodul meldet damit die erfolgreiche Übertragung einer PDU oder das Fehlschlagen des Sendevorgangs an das Modul Com zurück [SWS_Com_00124].

Aufrufkontext und Parameter

Die Funktion wird synchron ausgeführt, besitzt die Service-ID 0x40 und liefert keinen Rückgabewert (void) [SWS_Com_00124]. Sie erwartet zwei Eingangsparameter:

• TxPduId (Typ PduIdType): Eindeutige Kennung der PDU, deren Übertragung abgeschlossen oder gescheitert ist [SWS_Com_00124].
• result (Typ Std_ReturnType): Ergebnisstatus des Sendevorgangs [SWS_Com_00124]. Der Wert E_OK bestätigt die erfolgte Übertragung der PDU, während E_NOT_OK ein Scheitern der PDU-Übertragung signalisiert [SWS_Com_00124].

Nebenläufigkeit und Einschränkungen

Com_TxConfirmation ist reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe PDU-ID [SWS_Com_00124]. Interpretation: Aufrufer aus der unterlagerten Schicht dürften aufeinanderfolgende oder unterbrechende Aufrufe mit derselben TxPduId aus verschiedenen Ausführungskontexten vermeiden müssen, damit der interne Verarbeitungsstatus des Moduls Com konsistent bleibt. Frage Q-146c1c92403b64fa (offen)

Fehlerbehandlung

Die Spezifikation definiert für diesen Service keine spezifischen Rückgabewerte und weist keine gesonderten DET- oder DEM-Fehlermeldungen aus [SWS_Com_00124]. Fehlerhafte Übertragungen werden ausschließlich über den Parameter result mit dem Fehlerwert E_NOT_OK an das Modul Com übermittelt [SWS_Com_00124].

Verwendung und Semantik

Die Funktion Com_TpTxConfirmation wird aufgerufen, nachdem eine I-PDU auf dem Netzwerk übertragen wurde, um das COM-Modul über das Ergebnis des Sendevorgangs zu benachrichtigen [SWS_Com_00725]. Über den Parameter id vom Typ PduIdType wird die übertragene I-PDU identifiziert, während result vom Typ Std_ReturnType anzeigt, ob die Übertragung erfolgreich war oder fehlschlug [SWS_Com_00725]. Die Funktion besitzt keinen Rückgabewert (void) und weist eine synchrone Ausführungssemantik auf [SWS_Com_00725]. Sie ist über die Header-Datei Com.h verfügbar und besitzt die Service-ID 0x48 [SWS_Com_00725].

Fehlerbehandlung

Die Fehlerübermittlung an dieser Schnittstelle erfolgt ausschließlich über den Parameter result, welcher den Erfolg oder Misserfolg des I-PDU-Transfers abbildet [SWS_Com_00725]. Spezifische Fehlercodes sowie Fehlermeldungen an das Default Error Tracer (DET) oder das Diagnostic Event Manager (DEM) Modul sind in der Funktionsspezifikation nicht ausgewiesen [SWS_Com_00725].

Nebenläufigkeit und Randbedingungen

Die Schnittstelle ist als reentrant spezifiziert und darf somit parallel ausgeführt werden [SWS_Com_00725]. Als zeitliche Randbedingung gilt, dass der Aufruf erst nach Abschluss der Übertragung der I-PDU auf dem Netzwerk erfolgen darf [SWS_Com_00725]. Interpretation: Aufgrund der Namenskonvention und Modulstruktur dürfte der Aufruf typischerweise durch ein unterlagertes Transportprotokoll-Modul initiiert werden. Frage Q-8320e76ff63f62ce (offen)

Die synchrone und reentrante Funktion Com_StartReception (verfügbar über Com.h, Service-ID 0x46) wird zu Beginn des Empfangs einer N-SDU aufgerufen, welche unfragmentiert als Single Frame (SF) oder fragmentiert über einen First Frame (FF) mit nachfolgenden Consecutive Frames (CF) übermittelt wird [SWS_Com_00691].

Über den Parameter id wird die I-PDU identifiziert und TpSduLength gibt die Gesamtlänge der zu empfangenden N-SDU an [SWS_Com_00691]. Der Zeiger info verweist auf Nutzdaten und Nutzlänge des ersten bzw. einzelnen Rahmens sowie auf zugehörige Metadaten; stehen weder Rahmendaten noch Metadaten bereit, wird NULL_PTR übergeben [SWS_Com_00691]. Über den Ausgabeparameter bufferSizePtr stellt die Funktion die verfügbare Puffergröße bereit, die das Transportprotokoll-Modul zur Ermittlung der Block Size (BS) nutzt [SWS_Com_00691]. Wird der Dienst mit einem TpSduLength von 0 aufgerufen, liefert er die aktuell maximal verfügbare Puffergröße [SWS_Com_00691].

Das Ergebnis der Anforderung wird als BufReq_ReturnType zurückgegeben [SWS_Com_00691]:

• BUFREQ_OK: Die Verbindung wird akzeptiert und der Empfang fortgesetzt; bufferSizePtr weist den verfügbaren Puffer aus oder signalisiert 0, falls kein Puffer in der angeforderten Größe bereitsteht [SWS_Com_00691].
• BUFREQ_E_NOT_OK: Die Verbindung wird abgewiesen und der Empfang abgebrochen; der Wert von bufferSizePtr bleibt unverändert [SWS_Com_00691].
• BUFREQ_E_OVFL: Es kann kein Puffer der geforderten Länge bereitgestellt werden, woraufhin der Empfang abbricht; bufferSizePtr bleibt unverändert [SWS_Com_00691].

Verwendung und Aufrufsemantik

Die synchrone Funktion Com_CopyRxData wird aufgerufen, um die empfangenen Daten eines I-PDU-Segments (N-PDU) an die obere Schicht zu übergeben [SWS_Com_00692]. Bei segmentierten Übertragungen stellt jeder aufeinanderfolgende Aufruf dieser Schnittstelle den jeweils nächsten Teil der gesamten I-PDU-Daten bereit [SWS_Com_00692].

Parameter und Pufferverwaltung

• id: Identifiziert die empfangene I-PDU eindeutig [SWS_Com_00692].
• info: Zeiger auf eine Struktur vom Typ PduInfoType. Sie übergibt über SduDataPtr den Zeiger auf den Quellpuffer und über SduLength die Anzahl der zu kopierenden Bytes [SWS_Com_00692]. Eine Angabe von 0 für SduLength dient dazu, die aktuell verfügbare Puffergröße der oberen Schicht abzufragen; in diesem reinen Abfragefall darf SduDataPtr auf NULL_PTR gesetzt sein [SWS_Com_00692].
• bufferSizePtr: Zeiger auf eine Variable vom Typ PduLengthType, in die die nach dem Kopiervorgang verbleibende Größe des Empfangspuffers geschrieben wird [SWS_Com_00692].

Rückgabewerte und Eigenschaften

Die Funktion liefert einen Status vom Typ BufReq_ReturnType zurück [SWS_Com_00692]:

• BUFREQ_OK: Die Daten wurden erfolgreich in den Zielpuffer kopiert [SWS_Com_00692].
• BUFREQ_E_NOT_OK: Das Kopieren der Daten ist fehlgeschlagen, weil ein Fehler aufgetreten ist [SWS_Com_00692].

Die Schnittstelle besitzt die Service-ID 0x44, ist als reentrant spezifiziert und über den Header Com.h verfügbar [SWS_Com_00692].

Die synchrone und reentrante Funktion Com_CopyTxData wird von unterlagerten Modulen (wie Transportprotokollen) aufgerufen, um Sendedaten für Segmente (N-PDUs) einer I-PDU schrittweise aus dem Sendepuffer des COM-Moduls abzurufen [SWS_Com_00693].

Verwendung und Parameter

Jeder Aufruf stellt den nächsten Teil der I-PDU-Daten bereit [SWS_Com_00693]:

• id: Identifiziert die zu übertragende I-PDU [SWS_Com_00693].
• info: Gibt über SduDataPtr den Zielpuffer und über SduLength die Anzahl der zu kopierenden Bytes an. Eine Länge von 0 ist zulässig, um Statusänderungen über retry zu übermitteln oder die verfügbare Datenmenge abzufragen; in diesem Fall darf SduDataPtr ein NULL_PTR sein [SWS_Com_00693].
• retry: Bestätigt gesendete Daten oder veranlasst Neuübertragungen. Ist retry ein NULL_PTR, dürfen Daten unmittelbar nach dem Kopieren aus dem Puffer entfernt werden. Zeigt retry auf eine RetryInfoType-Struktur, steuert TpDataState die Pufferhaltung: TP_CONFPENDING belässt Daten für Fehlerbehebungen im Puffer, TP_DATACONF bestätigt vor dem Aufruf kopierte Daten zur Löschung, und TP_DATARETRY kopiert zuvor gelesene Daten ab dem Offset TxTpDataCnt erneut [SWS_Com_00693].
• availableDataPtr: Gibt die verbleibende Anzahl verfügbarer Bytes im Sendepuffer zurück, was beispielsweise dynamischen Transportprotokollen (wie FrIsoTp) die Bestimmung nachfolgender Segmentgrößen ermöglicht [SWS_Com_00693].

Rückgabewerte und Fehlerbehandlung

Das Funktionsergebnis signalisiert den Erfolg der Pufferanforderung über BufReq_ReturnType [SWS_Com_00693]:

• BUFREQ_OK: Daten wurden vollständig wie angefordert in den Zielpuffer kopiert [SWS_Com_00693].
• BUFREQ_E_BUSY: Die angeforderte Datenmenge steht im Sendepuffer nicht bereit. Es werden keine Daten kopiert, und das unterlagerte Modul darf den Aufruf zu einem späteren Zeitpunkt wiederholen [SWS_Com_00693].
• BUFREQ_E_NOT_OK: Die Anforderung ist fehlgeschlagen; es wurden keine Daten kopiert [SWS_Com_00693].

Verwendung

Die synchrone Funktion Com_MainFunctionRx übernimmt die interne Empfangsverarbeitung des AUTOSAR-COM-Moduls für Vorgänge, die nicht unmittelbar im Ausführungskontext der vom PDU-Router (PduR) aufgerufenen APIs wie Com_RxIndication abgearbeitet werden [SWS_Com_00398]. Sie besitzt weder Eingangs- noch Ausgangsparameter und liefert keinen Rückgabewert [SWS_Com_00398]. Die Deklaration erfolgt über den Header SchM_Com.h; der Aufrufkontext dürfte daher typischerweise periodisch durch den Schedule Manager (SchM) erfolgen [SWS_Com_00398]. Frage Q-48d121e36f62c6de (offen)

Fehlerbehandlung und Initialisierung

Wird die Funktion vor der Modulinitialisierung durch Com_Init oder nach einem Aufruf von Com_DeInit ausgeführt, wird im Gegensatz zu den meisten regulären COM-APIs kein Fehler COM_E_UNINIT (0x02) erzeugt, da Com_MainFunctionRx davon explizit ausgenommen ist [SWS_Com_00804]. Spezifische Fehler- oder Rückgabecodes existieren für diese Schnittstelle nicht [SWS_Com_00398].

Nebenläufigkeit und Multi-Instanz-Betrieb

Hinsichtlich des Ausführungskontexts und der Reentranz gelten folgende Vorgaben [SWS_Com_00398]:

• Reentranz: Die Funktion ist für dieselbe Instanz nicht reentrant, darf jedoch für unterschiedliche Instanzen parallel aufgerufen werden [SWS_Com_00398].
• Instanzspezifische Ausprägung: Für jeden in der ECU-Konfiguration definierten Container ComMainFunctionRx wird eine eigenständige Funktion in der Form Com_MainFunctionRx_<shortName> implementiert, wobei <shortName> dem Short-Name des Konfigurationscontainers entspricht [SWS_Com_00398].

Verwendung und Funktionsweise

Die Funktion Com_MainFunctionTx führt die Sendeaktivitäten des AUTOSAR-COM-Moduls aus, die nicht direkt innerhalb der durch die RTE aufgerufenen COM-Funktionen (wie beispielsweise Com_SendSignal) abgewickelt werden ([SWS_Com_00399]). Die Ausführung erfolgt synchron. Sie besitzt weder Eingabe-, Ein-/Ausgabe- noch Ausgabeparameter und liefert keinen Rückgabewert zurück ([SWS_Com_00399]). Die Schnittstelle wird über SchM_Com.h deklariert; Interpretation: Aufgrund dieser Header-Zugehörigkeit dürfte der Aufrufkontext im Schedule-Management (SchM) liegen. Frage Q-c33cfcf81700bcc5 (offen)

Für jeden konfigurierten Container einer Com Main Function Tx in der ECU-Konfiguration ist eine spezifische Instanzfunktion nach dem Namensschema Com_MainFunctionTx_<shortName> zu implementieren, wobei <shortName> dem Kurznamen des Konfigurationscontainers entspricht ([SWS_Com_00399]).

Nebenläufigkeit und Einschränkungen

Bezüglich der Reentranz ist Com_MainFunctionTx für unterschiedliche Instanzen reentrant ausgelegt, darf jedoch für dieselbe Instanz nicht reentrant aufgerufen werden ([SWS_Com_00399]).

Fehlerbehandlung und Initialisierungszustand

Gemäß [SWS_Com_00804] führt der Aufruf von COM-Diensten vor der Initialisierung über Com_Init oder nach der Deinitialisierung via Com_DeInit regulär zum Fehler COM_E_UNINIT (0x02). Com_MainFunctionTx ist hiervon jedoch explizit ausgenommen und erzeugt in diesen Zuständen keinen solchen Initialisierungsfehler ([SWS_Com_00804]).

Die Hauptfunktion Com_MainFunctionRouteSignals (Service-ID 0x1a) dient im AUTOSAR-COM-Modul als zentrale synchrone Schnittstelle für die Signalweiterleitung ([SWS_Com_00400]). Ihre Aufgabe besteht darin, den Signal-Gateway-Teil des COM-Moduls aufzurufen, damit empfangene Signale, die für ein Routing vorgesehen sind, an ihre konfigurierten Ziele weitergeleitet werden ([SWS_Com_00400]).

Aufruf und Semantik

Die parameterlose C-Schnittstelle besitzt die Signatur void Com_MainFunctionRouteSignals(void) ([SWS_Com_00400]). Sie wird synchron ausgeführt und besitzt weder Parameter für Eingabe, Ein-/Ausgabe oder Ausgabe noch einen Rückgabewert ([SWS_Com_00400]). Die Deklaration der Hauptfunktion wird über die Header-Datei SchM_Com.h zur Verfügung gestellt ([SWS_Com_00400]). Interpretation: Wegen dieser Bereitstellung über SchM_Com.h dürfte der planmäßige Aufruf im Task-Kontext periodisch durch den BSW-Scheduler (SchM) erfolgen. Frage Q-0f0b57034d6d6bf1 (offen)

Instanziierung und Reentranz

Für die Integration, Namensgebung und Nebenläufigkeit definiert [SWS_Com_00400] folgende bindende Anforderungen:

• Instanzspezifische Implementierung: Für jede in der ECU-Konfiguration vorhandene Instanz des Konfigurationscontainers ComMainFunctionRouteSignals muss eine eigene Funktion nach dem Namensschema Com_MainFunctionRouteSignals_<shortName> implementiert werden ([SWS_Com_00400]). Dabei entspricht <shortName> dem Kurznamen des betreffenden Konfigurationscontainers.
• Reentranz-Verhalten: Die Funktion ist reentrant für Aufrufe unterschiedlicher Instanzen ([SWS_Com_00400]). Für ein und dieselbe Instanz ist sie jedoch explizit nicht reentrant und darf daher nicht nebenläufig ausgeführt werden ([SWS_Com_00400]).

Die Callback-Funktion Com_CbkTxAck dient im Modul Com der Benachrichtigung über das erfolgreiche Senden einer Botschaft [SWS_Com_00468]. Sie repräsentiert die Benachrichtigungsklasse 2 (notification class 2) und wird unmittelbar nach der erfolgreichen Übertragung derjenigen I-PDU aufgerufen, welche die betreffende Botschaft enthält [SWS_Com_00468].

Für den Aufrufkontext und die Schnittstelleneigenschaften gelten gemäß Spezifikation folgende Vorgaben [SWS_Com_00468]:

• Signatur und Parameter: Die Callback-Funktion besitzt die Signatur void Com_CbkTxAck (void). Sie nimmt weder Eingangs-, Ein-/Ausgangs- noch Ausgangsparameter entgegen und liefert keinen Rückgabewert zurück [SWS_Com_00468].
• Synchronität: Der Aufruf ist als synchron (Synchronous) spezifiziert [SWS_Com_00468].
• Reentranz: Das Reentranzverhalten ist mit don't care klassifiziert [SWS_Com_00468].
• Konfiguration: Die Schnittstelle ist als konfigurierbar (configurable) deklariert [SWS_Com_00468]. Interpretation: Der tatsächliche Name der Callback-Funktion dürfte im Konfigurationswerkzeug nachrichten- oder signalspezifisch parametriert werden. Frage Q-3670b7b04fd7c74c (offen)

Spezifische Fehlercodes, Fehlerreaktionen sowie Meldungen an DET oder DEM sind für dieses Element in der Spezifikation nicht definiert [SWS_Com_00468]. Auch weiterführende Reihenfolgebedingungen gegenüber anderen Aufrufen werden nicht aufgeführt [SWS_Com_00468].

Die Callback-Funktion Com_CbkTxErr wird synchron aufgerufen, wenn eine Übertragung nicht möglich ist, weil die zugehörige I-PDU-Gruppe gestoppt ist [SWS_Com_00491]. Sie entspricht der Benachrichtigungsklasse 4 gemäß den zugrundeliegenden Spezifikationen [SWS_Com_00491].

Aufruf und Semantik

• Signatur und Parameter: Die Funktion besitzt weder Eingabe-, Ein-/Ausgabe- noch Ausgabeparameter (void Com_CbkTxErr (void)) und liefert keinen Rückgabewert zurück [SWS_Com_00491].
• Ausführungsverhalten: Der Aufruf erfolgt synchron („Synchronous“), während für die Reentranz „don't care“ spezifiziert ist [SWS_Com_00491].
• Verfügbarkeit: Die Callback-Schnittstelle ist konfigurierbar („configurable“) [SWS_Com_00491].

Fehlerbehandlung und Zusammenspiel

Die Funktion dient spezifisch dazu, den Fehlerfall einer verhinderten Sendeanforderung aufgrund einer gestoppten I-PDU-Gruppe an die aufrufende bzw. übergeordnete Schicht zu signalisieren [SWS_Com_00491]. Da keine Parameter übergeben werden, dürfte der Kontext des betroffenen Signals oder der I-PDU vermutlich über die Konfiguration oder modulspezifische Zuordnungen vorgegeben sein. Frage Q-d7153324d2eb2995 (offen)

Verwendung und Aufrufkontext

Die Callback-Funktion Com_CbkTxTOut dient als Benachrichtigungsschnittstelle über das Ausbleiben einer erfolgreichen Übertragung. Gemäß [SWS_Com_00554] wird sie unmittelbar aufgerufen, nachdem der Mechanismus zur Fristüberwachung (deadline monitoring mechanism) einen Übertragungsfehler einer Nachricht detektiert hat. Der Aufruf erfolgt synchron und entspricht der Benachrichtigungsklasse 4. Da die Signatur void Com_CbkTxTOut(void) weder Übergabe- noch Rückgabewerte besitzt, erfolgt die Signalisierung an die übergeordnete Schicht parameterlos.

Nebenläufigkeit und Konfiguration

Bezüglich der Reentranz ist die Funktion laut [SWS_Com_00554] mit don't care spezifiziert. Vermutlich obliegt es daher der aufgerufenen Anwendungssoftware, geeignete Maßnahmen zur Thread-Sicherheit zu treffen, falls Überwachungsereignisse nebenläufig eintreffen können. Frage Q-793a6c18d81de85e (offen) Die Verfügbarkeit der Callback-Funktion ist im Kommunikationsmodul konfigurierbar und wird an die jeweiligen Überwachungsanforderungen angepasst.

Fehlerbehandlung

In [SWS_Com_00554] sind für Com_CbkTxTOut keine gesonderten DET- oder DEM-Fehlermeldungen und keine Rückgabewerte zur Fehlerquittierung definiert. Das Auslösen des Callbacks stellt selbst die Fehlerreaktion auf eine überschrittene Sendefrist dar.

Die Callback-Funktion Com_CbkRxAck dient im AUTOSAR-COM-Modul als konfigurierbare Empfangsbestätigung und repräsentiert die Benachrichtigungsklasse 1 gemäß [17] [SWS_Com_00555]. Das COM-Modul ruft diese Callback-Routine unmittelbar auf, nachdem eine empfangene Nachricht erfolgreich im dafür vorgesehenen Empfangsnachrichtenobjekt abgelegt und gespeichert worden ist [SWS_Com_00555].

Verwendung und Aufrufkontext

• Synchrones Ausführungsverhalten: Die Funktion ist als synchron spezifiziert [SWS_Com_00555]. Sie wird direkt im Zuge des Speichervorgangs ausgeführt, sodass der aufrufende Kontext des COM-Moduls die Ausführung des Callbacks abwartet.
• Parameter und Rückgabewerte: Gemäß der Signatur void Com_CbkRxAck (void) werden keine Eingangsparameter, keine Ein-/Ausgangsparameter und keine Ausgangsparameter übergeben [SWS_Com_00555]. Die Funktion liefert zudem keinen Rückgabewert an das aufrufende Modul zurück [SWS_Com_00555].
• Verfügbarkeit: Der Aufrufmechanismus steht dem System als konfigurierbare Schnittstelle zur Verfügung [SWS_Com_00555].

Nebenläufigkeit und Fehlerbehandlung

Für die Reentranz ist die Eigenschaft „don't care“ festgelegt [SWS_Com_00555]. Dies dürfte bedeuten, dass die COM-Spezifikation keine Anforderungen an einen wiedereintrittsfähigen Aufruf stellt und Schutzmechanismen gegen gleichzeitigen Zugriff in der Verantwortung des Anwenders liegen. Frage (offen) Da weder Rückgabewerte noch spezifische Fehlercodes oder Fehlermeldungen für DET oder DEM definiert sind [SWS_Com_00555], dürften etwaige Fehler bei der Verarbeitung vollständig lokal innerhalb der Callback-Funktion behandelt werden müssen.

Verwendung und Semantik

Die Callback-Funktion Com_CbkRxTOut dient der Benachrichtigung über das Ausbleiben einer erwarteten Nachricht. Gemäß [SWS_Com_00556] wird sie unmittelbar aufgerufen, sobald der Deadline-Monitoring-Mechanismus des Moduls einen Fehler beim Nachrichtenempfang feststellt. Diese Benachrichtigung entspricht der Meldeklasse 3 („notification class 3 of [17]“) und steht als konfigurierbare Schnittstelle zur Verfügung [SWS_Com_00556].

Der Aufruf erfolgt synchron (Synchronous) ohne Übergabeparameter und ohne Rückgabewert (void Com_CbkRxTOut(void)) [SWS_Com_00556]. Die Funktion signalisiert dem aufrufenden Empfänger bzw. der übergeordneten Softwareschicht somit rein das Timeout-Ereignis selbst, ohne Kontextdaten direkt im Aufruf zu übermitteln.

Nebenläufigkeit und Einschränkungen

Für die Reentranz der Funktion ist in der Spezifikation don't care festgelegt [SWS_Com_00556]. Da der Aufruf unmittelbar und synchron nach der Fehlererkennung erfolgt, dürfte die Implementierung der Callback-Routine vermutlich so ausgelegt werden müssen, dass sie blockadearm abläuft, um das Deadline-Monitoring des COM-Moduls nicht unzulässig zu verzögern. Frage Q-88055efc50f5843b (offen)

Die Callback-Funktion Com_CbkInv benachrichtigt übergeordnete Softwareschichten über den Empfang fehlerhafter oder ungültiger Kommunikationsdaten im AUTOSAR COM-Modul [SWS_Com_00536]. Sie wird unmittelbar nach dem Empfang eines ungültigen Signals beziehungsweise einer ungültigen Signalgruppe aufgerufen und informiert den Empfänger über das Vorliegen eines ungültigen Signalwerts [SWS_Com_00536].

Die Schnittstelle besitzt die Signatur void Com_CbkInv(void), nimmt folglich keine Übergabeparameter entgegen und liefert keinen Rückgabewert an den Aufrufer [SWS_Com_00536]. Der Aufruf erfolgt synchron, während das Reentranzverhalten in der Spezifikation mit „don't care“ angegeben ist [SWS_Com_00536]. Da keine Parameter zur Identifikation des betroffenen Signals übergeben werden, dürfte der Bezeichner Com_CbkInv vermutlich als konfigurierbare Signaturschablone für signalspezifische Benachrichtigungen dienen. Frage Q-6e02e6bcf324eb93 (offen)

Hinsichtlich der Einbindung und des Systemverhaltens gelten folgende Randbedingungen:

• Die Bereitstellung der Funktion ist konfigurierbar, womit die Benachrichtigung bei Bedarf je Signal oder Signalgruppe aktiviert werden kann [SWS_Com_00536].
• Fachlich korrespondiert die Funktion mit der Anforderung SWS_Com_00680 für die Invalidierungsbehandlung empfangener Signale im COM-Modul [SWS_Com_00536].
• Spezifische Fehlerbehandlungsroutinen, Fehlercodes oder Fehlermeldungen an Entwicklungs- oder Diagnosemodule wie DET oder DEM sind für diese Schnittstelle nicht ausgewiesen [SWS_Com_00536].

Die konfigurierbare Callback-Funktion Com_CbkCounterErr dient der Signalisierung von Fehlern bei der I-PDU-Zählerüberwachung gemäß [SWS_Com_00726]. Sie wird unmittelbar und synchron vom AUTOSAR-COM-Modul aufgerufen, wenn bei einer empfangenen I-PDU ein Zählerwert erkannt wird, der nicht mit dem erwarteten Zählerwert übereinstimmt. Dies ermöglicht die frühzeitige Erkennung von Sequenzfehlern beim Nachrichtenempfang.

Die Schnittstelle besitzt keinen Rückgabewert (void) und übergibt beim Aufruf drei Eingabeparameter zur Fehleranalyse ([SWS_Com_00726]):

• ComPduId (PduIdType): Kennung der betroffenen I-PDU, bei welcher der Zählerfehler aufgetreten ist.
• ExpectedCounter (uint8): Der vom COM-Modul erwartete Zählerwert der I-PDU.
• ReceivedCounter (uint8): Der in der empfangenen Botschaft tatsächlich vorgefundene Zählerwert.

Bezüglich der Nebenläufigkeit ist die Reentranz der Funktion in der Spezifikation mit „don't care“ deklariert ([SWS_Com_00726]). Spezifische DET- oder DEM-Fehlermeldungen sind für diese Schnittstelle in [SWS_Com_00726] nicht vorgegeben. Da die Callback-Funktion als konfigurierbar definiert ist, dürfte sie vermutlich in einer übergeordneten Schicht wie der Applikation implementiert werden, um anwendungsspezifisch auf Übertragungsfehler oder Paketverluste zu reagieren. Interpretation: Da der Aufruf unmittelbar und synchron im Kontext der COM-Empfangsverarbeitung erfolgt ([SWS_Com_00726]), dürfte die aufgerufene Routine keine blockierenden Operationen durchführen. Frage Q-a745eb5416fc156b (offen)

Die Callback-Funktion Com_CbkTxPrep dient als Benachrichtigung darüber, dass die Signale beziehungsweise Signalgruppen einer dedizierten Instanz von Com_MainFunctionTx nun für die Übertragung vorbereitet werden [SWS_Com_91013]. Die Ausführung der Funktion erfolgt synchron zur aufrufenden Instanz [SWS_Com_91013]. Gemäß ihrer Signatur void Com_CbkTxPrep(void) nimmt sie weder Eingabeparameter noch Ein- und Ausgabeparameter oder Ausgabeparameter entgegen und besitzt keinen Rückgabewert [SWS_Com_91013].

Die Bereitstellung der Schnittstelle steht über eine Konfiguration zur Verfügung [SWS_Com_91013]. Sofern der Konfigurationsparameter ComPreparationNotification konfiguriert ist, muss die jeweilige Funktion Com_CbkTxPrep innerhalb der zugehörigen MainFunctionTx aufgerufen werden [SWS_Com_00886]. Dabei ist eine feste zeitliche Reihenfolgebedingung zwingend einzuhalten: Der Aufruf muss vollständig stattfinden, bevor die eigentliche Verarbeitung der I-PDUs innerhalb der Tx-Hauptfunktion gestartet wird [SWS_Com_00886].

Hinsichtlich des Nebenläufigkeitsverhaltens und möglicher Einschränkungen ist Com_CbkTxPrep als nicht reentrant (Non Reentrant) spezifiziert [SWS_Com_91013]. Der Aufrufkontext ist fest an den Ablauf der jeweiligen Instanz von MainFunctionTx gebunden [SWS_Com_91013]. Da der Callback unmittelbar vor Beginn der I-PDU-Verarbeitung ausgeführt werden muss, ist die Funktion synchron in die entsprechende Senderoutine eingegliedert [SWS_Com_00886].

Die Funktion Com_RxIpduCallout ist ein konfigurierbarer Callout auf Empfängerseite, der zur Implementierung anwenderspezifischer Empfangsfiltermechanismen für I-PDUs dient [SWS_Com_00700]. Die Ausführung erfolgt synchron, und hinsichtlich der Reentranz ist die Schnittstelle als don't care spezifiziert [SWS_Com_00700].

Dem Aufruf werden die Kennung sowie die Daten der empfangenen PDU übergeben [SWS_Com_00700]:

• PduId: Identifikator der empfangenen I-PDU [SWS_Com_00700].
• PduInfoPtr: Zeiger auf eine PduInfoType-Struktur, welche die Länge (SduLength) sowie einen Zeiger auf die Nutzdaten (SduDataPtr) der empfangenen I-PDU bereitstellt [SWS_Com_00700].

Bezüglich der Datenbereitstellung fordert [SWS_Com_00816], dass das Modul AUTOSAR COM alle Daten der empfangenen I-PDU vollständig an Com_RxIpduCallout weiterleitet, exakt so, wie sie von der PDU-Router-Schicht (PduR) bereitgestellt wurden.

Über den booleschen Rückgabewert steuert der Callout die nachfolgende Verarbeitung der I-PDU im COM-Modul [SWS_Com_00700]:

• true: Die empfangene I-PDU wird normal weiterverarbeitet [SWS_Com_00700].
• false: Die I-PDU wird nicht weiterverarbeitet und somit verworfen [SWS_Com_00700].

Spezifische Fehlercodes, Rückmeldecode-Konstanten oder DET- und DEM-Meldungen sind für diesen Callout in der Spezifikation nicht vorgesehen [SWS_Com_00700].

Die Funktion Com_TxIpduCallout dient als konfigurierbarer Callout auf Senderseite und wird synchron aufgerufen, um eine anwenderspezifische Vorverarbeitung oder Übertragungsfilterung einer ausgehenden I-PDU durchzuführen [SWS_Com_00346].

Parameter und Rückgabewert

• PduId (in): Übergibt die Kennung der zu übertragenden I-PDU [SWS_Com_00346].
• PduInfoPtr (inout): Enthält die Nutzdatenlänge (SduLength) sowie einen Zeiger auf die Nutzdaten (SduDataPtr) der I-PDU [SWS_Com_00346]. Hierüber können die I-PDU-Daten vor dem Senden inspiziert oder modifiziert werden.
• Rückgabewert (boolean): Steuert die weitere Verarbeitung der I-PDU [SWS_Com_00346]. Ein Rückgabewert von true veranlasst den regulären Versand der I-PDU, während false jegliche Weiterverarbeitung und damit die Übertragung abbricht [SWS_Com_00346].

Nebenläufigkeit und Konfiguration

Der Callout besitzt die Service-ID 0x29 und seine Reentrancy ist spezifikationsseitig mit „don't care“ definiert [SWS_Com_00346]. Interpretation: Da die Reentranz unbeschränkt ist, dürften Aufrufe abhängig vom auslösenden Sendeauftrag in unterschiedlichen Task-Kontexten stattfinden, weshalb anwenderseitige Implementierungen bei geteilten Ressourcen threadsicher sein sollten. Frage Q-3ce35701879bb60c (offen)

Der Enumerationstyp Com_StatusType definiert den Statuswert für das AUTOSAR-COM-Modul und wird über die Header-Datei Com.h bereitgestellt [SWS_Com_00819]. Dieser Typ dient als Rückgabewert des API-Dienstes Com_GetStatus(), mit welchem Aufrufer den aktuellen Initialisierungs- und Betriebszustand des Kommunikationsmoduls abfragen können [SWS_Com_00819].

Der spezifizierte Wertebereich von Com_StatusType unterscheidet genau zwei Zustände [SWS_Com_00819]:

• COM_UNINIT: Zeigt an, dass das AUTOSAR-COM-Modul nicht initialisiert oder nicht verwendbar ist [SWS_Com_00819]. Dieser Zustand besitzt zwingend den numerischen Wert 0x00 (bzw. Wert 0) und bildet den verbindlichen Standardwert unmittelbar nach einem Reset des Systems [SWS_Com_00819].
• COM_INIT: Signalisiert, dass das AUTOSAR-COM-Modul ordnungsgemäß initialisiert wurde und somit betriebsbereit und verwendbar ist [SWS_Com_00819].

Für die aufrufende Software dient die Auswertung dieses Rückgabewerts der Überprüfung der Einsatzbereitschaft des Kommunikationsmoduls vor dessen Verwendung [SWS_Com_00819]. Solange der Dienst Com_GetStatus() den Wert COM_UNINIT zurückgibt, gilt das COM-Modul als nicht initialisiert oder nicht verwendbar [SWS_Com_00819]. Erst wenn der Status den Wert COM_INIT aufweist, ist das Modul initialisiert und betriebsbereit [SWS_Com_00819]. Weitere Fehlercodes oder Rückgabewerte sind für diesen Aufzählungstyp nicht spezifiziert [SWS_Com_00819].