class <SI-Namespace>::proxy::fields::<Field>

Verwendung

Die Methode Get dient im Proxy-Scope <SI-Namespace>::proxy::fields::<Field> dem asynchronen Abruf des aktuellen Feldwerts ([SWS_CM_00112]; siehe auch AUTOSAR_AP_EXP_ARAComAPI §6 „FieldGet“). Die Funktion wird über den Proxy-Header <SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h bereitgestellt und existiert nur dann, wenn für das Feld Field.hasGetter == TRUE modelliert ist ([SWS_CM_00112]). Sie nimmt keine Parameter entgegen und liefert ein ara::core::Future<FieldType> zurück, welches nach erfolgreicher Übertragung den aktuellen Wert enthält ([SWS_CM_00112]).

Fehlerbehandlung und Randbedingungen

Die Schnittstelle ist als noexcept und exceptionsicher definiert ([SWS_CM_00112]). Schlägt die Operation fehl, enthält das zurückgegebene ara::core::Future einen Fehlercode mit Rollback-Semantik ([SWS_CM_00112]):

• ComErrc::kCommunicationFailure: Das Netzwerk-Binding meldet einen behebbaren Kommunikationsfehler oder das Fehlschlagen einer gesicherten Kommunikation ([SWS_CM_00112]).
• ComErrc::kMinimumSendIntervalViolationError: Eine Sendeanforderung erfolgte schneller als das für das Element konfigurierte Mindestsendeintervall (minimumSendInterval) erlaubt ([SWS_CM_00112]).
• InsufficientPermissionsViolation: Die Ausführung wird durch das Grant Enforcement abgewiesen ([SWS_CM_00112]).

Anwendungsfehler (Application Errors) existieren für den Getter nicht ([SWS_CM_00113]).

Zusammenspiel

Auf der Skeleton-Seite setzt die Bearbeitung der Getter-Anfrage einen Callback voraus, der über RegisterGetHandler hinterlegt wird ([SWS_CM_00114]). Jeder Aufruf von Get() führt eine End-to-End-Prüfung (E2E) aus; der daraus resultierende Zustandsstatus kann auf Proxy-Seite synchron über GetE2EStateMachineStateGetter abgefragt werden ([SWS_CM_00145]).

Verwendung und Aufrufkontext

Die Funktion Set wird im Namensraum <SI-Namespace>::proxy::fields::<Field> bereitgestellt und steht ausschließlich dann zur Verfügung, wenn für das Feld Field.hasSetter == TRUE konfiguriert ist [SWS_CM_00113]. Vor der Verwendung muss die Service-Instanz serverseitig angeboten (OfferService()) und clientseitig gefunden sowie verbunden worden sein ARAComAPI §4.2 „Means of Communication“. Der Aufruf erfolgt asynchron: Er übergibt den neuen Feldwert über den Parameter value und liefert ein ara::core::Future<FieldType> zurück [SWS_CM_00113]. Die Methode ist als noexcept spezifiziert und gilt als ausnahmesicher [SWS_CM_00113].

Fehlerbehandlung

Schlägt die Übertragung fehl, wird der entsprechende Fehler über das zurückgegebene ara::core::Future bereitgestellt [SWS_CM_00113]:

• ComErrc::kCommunicationFailure: Meldet einen behebbaren Kommunikationsfehler oder eine Störung der sicheren Übertragung; im Falle eines Timeouts kann ein unbestimmter Zustand auf Serverseite ohne Rollback-Semantik vorliegen [SWS_CM_00113].
• ComErrc::kMinimumSendIntervalViolationError: Tritt auf, wenn eine Sendeanforderung schneller als das konfigurierte Mindestsendeintervall (minimumSendInterval) abgesetzt wurde (ebenfalls ohne Rollback-Semantik) [SWS_CM_00113].
• Fehlende Zugriffsrechte führen zu einer Verweigerung durch Grant Enforcement (InsufficientPermissionsViolation) [SWS_CM_00113].
• Anwendungsfehler werden nicht über Ausnahmen transportiert, sondern indem im Erfolgsfall des Futures ein vom Anforderungsparameter abweichender Wert zurückgeliefert wird [SWS_CM_00113].

Zusammenspiel und Nebenläufigkeit

Auf Serverseite korrespondiert der Aufruf mit einem Callback an der Skeleton-Instanz, der zuvor mittels RegisterSetHandler hinterlegt werden muss [SWS_CM_00116] ARAComAPI §4.2 „Means of Communication“. Zur Überwachung der E2E-Übertragungssicherheit auf Clientseite kann der Status der E2E-Zustandsmaschine des letzten Set()-Aufrufs über GetE2EStateMachineStateSetter() abgefragt werden [SWS_CM_00146].

Verwendung und Aufrufkontext

Die Funktion SetReceiveHandler wird proxyseitig im Namensraum <SI-Namespace>::proxy::fields::<Field> über die Header-Datei <SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h bereitgestellt ([SWS_CM_11605]). Sie registriert auf Client-Seite einen Callback für Benachrichtigungen bei Wertänderungen eines Feldes ([SWS_CM_11605]). Dieser Mechanismus folgt dem Benachrichtigungsverfahren von Events, wodurch das Communication Management den Client bei Aktualisierungen informiert (EXP_ARAComAPI §4.2 „Means of Communication“).

Als Parameter wird ein ara::com::FieldReceiveHandler übergeben, der eine parameterlose Funktion darstellt ([SWS_CM_11605]). Die Funktion liefert keinen Rückgabewert (void) zurück und ist als ausnahmesicher (noexcept) spezifiziert ([SWS_CM_11605]).

Fehlerbehandlung und Nebenläufigkeit

Falls das übergebene Callable-Objekt nicht existiert oder null ist, meldet die Funktion die Verletzung InvalidHandlerViolation ([SWS_CM_11605]). Wenn die Ausführung des Handlers in einem definierten Ausführungskontext erfolgen soll, steht die Template-Variante mit ExecutorT zur Verfügung ([SWS_CM_11611]).

Zusammenspiel

Das Verhalten entspricht den Handler-Registrierungen für Events ([SWS_CM_00181]) und Trigger ([SWS_CM_00250]). Eine Aufhebung der Registrierung dürfte dem Schnittstellenmuster der Proxy-Klasse folgend über UnsetReceiveHandler() stattfinden (EXP_ARAComAPI §5.3.1 „Proxy Class API’s“). Frage Q-74cd83b99aadec16 (offen)

Verwendung und Aufrufkontext

Die Template-Funktion SetReceiveHandler ist Teil der Proxy-Klasse class <SI-Namespace>::proxy::fields::<Field> ([SWS_CM_11611]; Header #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h"). Sie dient dazu, auf Clientseite einen Empfangshandler für Benachrichtigungen bei Wertänderungen eines Feldes zu registrieren (AUTOSAR_AP_EXP_ARAComAPI §4.2 „Means of Communication“, [SWS_CM_11605]). Über die Parameter werden ein aufrufbares Objekt handler vom Typ ara::com::FieldReceiveHandler sowie ein Ausführungskontext executor als universelle Referenz ExecutorT&& übergeben ([SWS_CM_11611]). Die Funktion besitzt keinen Rückgabewert (void).

Fehlerbehandlung und Exception-Sicherheit

Die Methode ist als noexcept deklariert und als ausnahmesicher (exception safe) spezifiziert ([SWS_CM_11611]). Wenn das übergebene Callable handler nicht existiert oder null ist, liegt eine InvalidHandlerViolation vor ([SWS_CM_11611]). Aufrufer müssen daher sicherstellen, dass vor dem Aufruf ein valides Funktions- oder Funktionsobjekt bereitgestellt wird.

Nebenläufigkeit und Zusammenspiel

Im Unterschied zur Standardregistrierung ohne Executor ([SWS_CM_11605]) wird der Callback bei Eintreffen einer Feld-Benachrichtigung in dem durch executor bereitgestellten Ausführungskontext abgearbeitet ([SWS_CM_11611]). Interpretation: Dies dürfte eine Entkopplung bewirken, sodass die anwendungsspezifische Datenverarbeitung nicht in den Ausführungskontexten interner Middleware-Threads erfolgt. Frage Q-cbe1af19bea15a88 (offen) Die Methode gehört zu den Proxy-Klassen-APIs (AUTOSAR_AP_EXP_ARAComAPI §5.3.1 „Proxy Class API’s“) und folgt dem gleichen Muster wie die Executor-Varianten für Events ([SWS_CM_11356] basierend auf [SWS_CM_00181]) sowie Trigger ([SWS_CM_00352] basierend auf [SWS_CM_00250]).

Die Funktion SetSubscriptionStateChangeHandler registriert auf einem Proxy-Feld (Scope <SI-Namespace>::proxy::fields::<Field>) einen benutzerdefinierten Callback, der vom Communication Management aufgerufen wird, sobald sich der Abonnementzustand (ara::com::SubscriptionState) des Feldes ändert ([SWS_CM_11607], [SWS_CM_00333]). Der Aufruf erfolgt synchron und liefert keinen Rückgabewert zurück ([SWS_CM_11607]). Sie zählt zu den zentralen Proxy-Schnittstellen zur Verwaltung von Ereignis- und Feld-Abonnements (AUTOSAR_AP_EXP_ARAComAPI §5.3.1 „Proxy Class API’s“).

Hinsichtlich der Fehlerbehandlung ist die Registrierungsfunktion als exception safe spezifiziert und mit noexcept deklariert ([SWS_CM_11607]). Falls das übergebene Callable-Objekt handler nicht existiert oder null ist, liegt ein Spezifikationsverstoß in Form einer InvalidHandlerViolation vor ([SWS_CM_11607]).

Im Zusammenspiel mit dem Verbindungsaufbau ist zu beachten, dass Subscribe() grundsätzlich als asynchrone Operation betrachtet werden muss ([SWS_CM_12006]). Anwendungen dürfen daher selbst nach fehlerfreier Rückkehr von Subscribe() erst dann von einem erfolgreichen Abonnement ausgehen, wenn der registrierte Handler den Zustand kSubscribed signalisiert hat ([SWS_CM_12006]). Zudem ruft das Communication Management den Handler mit kSubscriptionPending auf, wenn die tatsächliche Bindung nicht sofort abgeschlossen werden kann oder die Serverinstanz beispielsweise infolge eines Neustarts oder Netzwerkfehlers ausfällt ([SWS_CM_00313]). Soll der Handler in einem spezifischen Ausführungskontext ausgeführt werden, steht hierfür die überladene Template-Variante mit einem ExecutorT bereit ([SWS_CM_11608]).

Die Template-Funktion SetSubscriptionStateChangeHandler im Namensraum <SI-Namespace>::proxy::fields::<Field> dient der Registrierung einer Callback-Funktion zur Überwachung von Zustandsänderungen des Abonnements eines Feldes ([SWS_CM_11608]). Sie erweitert das Basisverhalten aus [SWS_CM_11607] darum, dass der registrierte Handler in einem explizit übergebenen Ausführungskontext (executor) ausgeführt wird ([SWS_CM_11608]).

Die Methode nimmt zwei Parameter entgegen ([SWS_CM_11608]):

• handler: Der aufzurufende Callback vom Typ ara::com::SubscriptionStateChangeHandler ([SWS_CM_11354]), welcher ausgelöst wird, sobald sich der ara::com::SubscriptionState ändert ([SWS_CM_00333]).
• executor: Eine Weiterleitungsreferenz vom Typ ExecutorT&& ([SWS_CM_11360]), die den Kontext für die Ausführung des Handlers bereitstellt ([SWS_CM_11608]).

Die Funktion liefert keinen Rückgabewert (void) und ist als noexcept deklariert ([SWS_CM_11608]). Sie ist exception safe spezifiziert ([SWS_CM_11608]). Als Verletzung ist InvalidHandlerViolation definiert, falls das übergebene Callable nicht existiert oder null ist ([SWS_CM_11608]).

Interpretation: Durch die Übergabe des executor dürfte die Ausführung des Handlers aus dem internen Kontext des Kommunikationsmanagements in den Thread- oder Aufgabenkontext der Anwendung verlagert werden. Frage Q-647f618545799c4e (offen) Im Zusammenspiel der Proxy-APIs reiht sich der Aufruf neben Methoden wie Subscribe(), Unsubscribe() und UnsetSubscriptionStateChangeHandler() ein (AUTOSAR_AP_EXP_ARAComAPI §5.3.1 „Proxy Class API’s“). Analoge überladene Varianten mit Ausführungskontext existieren für Proxy-Events ([SWS_CM_11354]) sowie Proxy-Trigger ([SWS_CM_01106]).

Verwendung und Aufrufkontext

Die Elementfunktion SetTransportFaultConditionHandler dient der Registrierung eines Fehler-Handlers für den Notifier eines Proxy-Felds im Namensraum <SI-Namespace>::proxy::fields::<Field> [SWS_CM_00109]. Als Parameter wird ein aufrufbares Objekt (Callable) vom Typ ara::com::e2e::TransportFaultConditionHandler übergeben. Die Funktion liefert keinen Rückgabewert und bindet den Callback an die Notifier einzelner Service-Instanzen, um Übertragungsfehler des Kommunikations-Backends entgegenzunehmen AUTOSAR_AP_SWS_CommunicationManagement §7.4 „End-to-end communication protection“ S. 235.

Fehlerbehandlung und Exception-Sicherheit

Die Methode ist als noexcept deklariert und als ausnahmesicher (exception safe) spezifiziert [SWS_CM_00109]. Ist das übergebene Callable ungültig oder null, liegt eine Verletzung der Vorbedingung in Form einer InvalidHandlerViolation vor [SWS_CM_00109]. Interpretation: Da die Funktion keine Ausnahmen werfen darf, dürfte eine solche Verletzung in AUTOSAR Adaptive typischerweise zum sofortigen Programmabbruch führen. Frage Q-74df6934d4ae3c93 (offen)

Nebenläufigkeit und Zusammenspiel

Während diese Grundform den Handler direkt registriert, existiert mit [SWS_CM_00110] eine überladene Template-Variante, die zusätzlich einen Executor (ExecutorT&& executor) zur Festlegung des asynchronen Ausführungskontextes entgegennimmt. Die Funktion reiht sich in die End-to-End-Fehlerbehandlung ein: Während Notifier ([SWS_CM_00109], [SWS_CM_00110]), Events ([SWS_CM_00099]) und Trigger ([SWS_CM_00106]) Übertragungsfehler asynchron über solche Handler melden, werden Transportfehler bei Methoden- sowie Getter- und Setter-Anfragen stattdessen über ComErrc::kCommunicationFailure im resultierenden ara::core::Future zurückgemeldet [SWS_CM_00090].

Verwendung

Die Template-Elementfunktion SetTransportFaultConditionHandler dient im Scope einer Proxy-Field-Klasse (<SI-Namespace>::proxy::fields::<Field>) zur Registrierung eines Handlers für den Notifier des jeweiligen Felds [SWS_CM_00110]. Sie nimmt zwei Eingabeparameter entgegen:

• handler: das zu registrierende Callable vom Typ ara::com::e2e::TransportFaultConditionHandler [SWS_CM_00110].
• executor: eine Rvalue-Referenz auf ein Executor-Objekt (ExecutorT&&), in dessen Ausführungskontext etwaige asynchron angestoßene Berechnungen gestartet werden [SWS_CM_00110].

Die Funktion liefert keinen Rückgabewert (void) und ist als noexcept deklariert [SWS_CM_00110].

Fehlerbehandlung und Ausführungssicherheit

Die Schnittstelle ist als exceptionsicher (exception safe) spezifiziert [SWS_CM_00110]. Wird als handler ein nicht existentes oder nullwertiges Callable übergeben, führt dies zu einer InvalidHandlerViolation [SWS_CM_00110]. Über diesen Handler werden spezifische Transportfehlerbedingungen gemeldet, wohingegen Methoden sowie Field-Getter und -Setter etwaige Transportfehler über ComErrc::kCommunicationFailure an ihren jeweiligen Rückgabe-Futures signalisieren [SWS_CM_00090].

Nebenläufigkeit und Zusammenspiel

Die Methode bildet die Execution-Context-Überladung zur parameterärmeren Basisfunktion [SWS_CM_00109]. Durch das übergebene Executor-Objekt entkoppelt die Implementierung die Handler-Ausführung vom internen Empfangskontext der Kommunikationsverwaltung [SWS_CM_00110]. Gleichartige Überladungen stehen für Proxy-Events [SWS_CM_00100], Proxy-Trigger [SWS_CM_00107] sowie für Skeleton-Methoden [SWS_CM_00094] und Skeleton-Fields [SWS_CM_00097] bereit. Interpretation: Der Aufruf dürfte sinnvollerweise vor dem Eintreffen von Notifier-Mitteilungen bzw. dem Abonnieren des Notifiers erfolgen, um eine lückenlose Fehlerüberwachung sicherzustellen. Frage Q-bc5c62dd39c09029 (offen)

Die Methode Subscribe dient dazu, Benachrichtigungen für ein Field einer Service-Proxy-Instanz im Scope proxy::fields::<Field> zu abonnieren ([SWS_CM_11601]). Über den Parameter maxSampleCount legt die Anwendung die maximale Anzahl an Daten-Samples fest, die sie gleichzeitig halten möchte, und richtet damit den lokalen Empfangscache ein ([SWS_CM_11601], EXP ARAComAPI §5.3 „Proxy Class API’s“). Der Aufruf ist asynchron: Das zurückgegebene ara::core::Result<void> signalisiert lediglich die Annahme des Abonnements durch das Communication Management (EXP ARAComAPI §5.3.5.2 „Monitoring Event Subscription“).

Hinsichtlich des Zustandsverhaltens und der Fehlerbehandlung gelten folgende Regeln:

• Idempotenz: Befindet sich das Field bereits im Zustand kSubscribed oder kSubscriptionPending und stimmt der übergebene maxSampleCount mit dem Wert der aktuellen Subskription überein, kehrt die Methode wirkungslos zurück ([SWS_CM_11601]).
• Fehlercodes: Kann der geforderte Cache nicht bereitgestellt werden, schlägt die Operation mit dem Fehler ComErrc::kMaxSampleCountNotRealizable fehl ([SWS_CM_11601], [SWS_CM_10432]).
• Berechtigungsprüfung: Fehlen die erforderlichen Rechte, wird der Aufruf durch das Grant Enforcement mit einer InsufficientPermissionsViolation abgewiesen ([SWS_CM_11601]).

Die Methode ist als noexcept deklariert und als Exception-safe spezifiziert ([SWS_CM_11601]). Semantisch folgt sie dem Verhalten der Event-Subskription ([SWS_CM_00141]); der konfigurierte Cache bildet die Grundlage für den anschließenden Sample-Empfang über Methoden wie GetNewSamples ([SWS_CM_00701]).

Die Funktion UnsetReceiveHandler() dient auf Proxy-Ebene dazu, einen zuvor registrierten Empfangs-Handler für Feld-Benachrichtigungen zu deregistrieren ([SWS_CM_11606]). Sie gehört zu den Proxy-Klassen-APIs von ara::com (AUTOSAR_AP_EXP_ARAComAPI §5.3.1 „Proxy Class API’s“) und ist im Namensraum <SI-Namespace>::proxy::fields::<Field> angesiedelt ([SWS_CM_11606]).

Hinsichtlich Aufrufkontext und Semantik nimmt die Methode keine Parameter entgegen und liefert keinen Rückgabewert ([SWS_CM_11606]). Durch den Aufruf kann eine Anwendung jederzeit von einem ereignisgesteuerten Benachrichtigungsmodell zu einem abfragebasierten Polling-Betrieb wechseln, indem der anwenderspezifische Callback zurückgezogen wird (AUTOSAR_AP_EXP_ARAComAPI §5.3.2 „RadarService Proxy Class Example“).

Für die Fehlerbehandlung ist die Funktion als noexcept sowie exception safe spezifiziert ([SWS_CM_11606]); spezifische Fehlercodes existieren laut Spezifikation nicht. Der Aufruf erfolgt synchron; nach erfolgreichem Entzug des Handlers löst das Communication Management bei neu eingehenden Daten keine weiteren Callback-Aufrufe mehr aus (Interpretation: laufende oder bereits eingeplante Ausführungen dürften vor dem Rückzug noch abgeschlossen bzw. serialisiert abgearbeitet werden, da Callback-Aufrufe durch das Communication Management serialisiert erfolgen müssen; vgl. AUTOSAR_AP_EXP_ARAComAPI §5.3.2 „RadarService Proxy Class Example“). Frage Q-fbc65e80b8d8be38 (offen)

Im Zusammenspiel korrespondiert die Methode mit dem Deaktivieren von Triggern bei Service-Events ([SWS_CM_00183]; AUTOSAR_AP_EXP_ARAComAPI §10) und Triggern ([SWS_CM_11614]). Im DDS-Binding wird das Verhalten über das Mapping von UnsetReceiveHandler() auf den jeweiligen DataReader abgebildet ([SWS_CM_11141]).

Verwendung

Die Methode UnsetSubscriptionStateChangeHandler dient im Rahmen der AUTOSAR-Adaptive-Plattform dazu, einen zuvor registrierten Callback für Änderungen des Abonnementstatus (ara::com::SubscriptionState) eines Feldes zu entfernen [SWS_CM_11609]. Sie wird synchron auf Instanzen von Feldern eines Dienst-Proxys im Namensraum <SI-Namespace>::proxy::fields::<Field> aufgerufen und erfordert die Einbindung des generierten Headers #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h" AUTOSAR_AP_SWS_CommunicationManagement §8.3.3.2.4.5 „UnsetSubscriptionStateChangeHandler“. Der Aufruf nimmt keine Übergabeparameter entgegen und liefert keinen Rückgabewert.

Fehlerbehandlung und Nebenläufigkeit

Die Schnittstelle ist als noexcept deklariert und erfüllt laut Spezifikation die Eigenschaft exception safe [SWS_CM_11609]. Ein Auftreten von Fehlern oder Exceptions ist somit ausgeschlossen. Da das Deregistrieren unmittelbar wirksam wird, ist davon auszugehen (Interpretation), dass nach Beendigung der Methode keine neuen Benachrichtigungen mehr an den vormaligen Handler übergeben werden. Frage Q-30238329b76b64f4 (offen)

Zusammenspiel

Die Funktion gehört zu den grundlegenden Proxy-Klassen-APIs zur Verwaltung von Abonnements in ara::com AUTOSAR_AP_EXP_ARAComAPI §5.3.1 „Proxy Class API’s“. Gleichartige Methoden zur Deaktivierung von Statusänderungs-Handlern existieren für Proxy-Events [SWS_CM_00334] und Trigger [SWS_CM_01108] sowie spiegelbildlich auf der Skeleton-Seite für Events [SWS_CM_12010] und Trigger [SWS_CM_01112].

Verwendung

Die Funktion UnsetTransportFaultConditionHandler dient dazu, einen zuvor registrierten ara::com::e2e::TransportFaultConditionHandler für den Notifier eines bestimmten Proxy-Feldes wieder abzumelden [SWS_CM_00126]. Sie ist innerhalb des Scopes <SI-Namespace>::proxy::fields::<Field> definiert und wird über die Header-Datei <SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h eingebunden AUTOSAR_AP_SWS_CommunicationManagement §8.3.3.2.1.4 „UnsetTransportFaultConditionHandler“. Der Aufruf erfolgt parameterlos und liefert keinen Rückgabewert (void).

Fehlerbehandlung

Die Methode ist als noexcept deklariert und besitzt die Ausnahme-Garantie exception safe [SWS_CM_00126]. Es werden keine Fehlercodes zurückgegeben oder Exceptions geworfen. Falls kein Handler zuvor registriert war, dürfte ein wiederholter Aufruf vermutlich ohne Auswirkung bleiben. Frage Q-85da9a7b00678748 (offen)

Nebenläufigkeit und Einschränkungen

Die Spezifikation definiert keine gesonderten Nebenläufigkeits- oder Thread-Sicherheitsanforderungen. Da die Schnittstelle synchron arbeitet und keine asynchronen Typen nutzt, dürfte das Zurücknehmen des Fehler-Handlers synchron und unmittelbar greifen. Frage Q-ed4cc712bb55aee5 (offen) Aufrufer sollten den Aufruf im Anwendungslebenszyklus so koordinieren, dass Notifier-Meldungen einzelner Service-Instanzen nicht unkontrolliert ohne Handler verarbeitet werden AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 „End-to-end communication protection for SOMEIP“.

Zusammenspiel

Das Deregistrieren folgt einem konsistenten Namens- und Funktionsmuster in AUTOSAR Adaptive:

• Auf Proxy-Ebene stehen äquivalente Funktionen für Events ([SWS_CM_00105]) sowie für Trigger ([SWS_CM_00108]) bereit.
• Auf Skeleton-Ebene existieren entsprechende Pendants für Field-Getter und -Setter ([SWS_CM_00098]) sowie übergreifend für alle Methoden des Skeleton-Interfaces ([SWS_CM_00095]).