Modul ara::com — Communication Management
Modul-GuideKI-GENERIERT
Stellt typisierte Schnittstellen für die serviceorientierte Kommunikation bereit und abstrahiert Transportprotokolle.
Stellt typisierte Schnittstellen für die serviceorientierte Kommunikation bereit und abstrahiert Transportprotokolle.
Das Functional Cluster Communication Management (ara::com) ermöglicht die serviceorientierte Interaktion zwischen Adaptive-Applikationen über standardisierte Proxy- und Skeleton-Schnittstellen (SWS_CommunicationManagement S. 55, ARAComAPI S. 1). Es regelt die dynamische Dienstfindung mittels OfferService() und FindService() ([SWS_CM_00101], [SWS_CM_00122]) und stellt synchrone sowie asynchrone Methoden, Events und Fields mit integrierter E2E- und SecOC-Absicherung bereit ([SWS_CM_00141], [SWS_CM_90420]). Bei vorübergehendem Verlust eines Dienstes fängt die Middleware Verbindungsunterbrechungen ab und aktualisiert bestehende Proxy-Objekte nach Wiederverfügbarkeit automatisch (ARAComAPI S. 32).
Das Functional Cluster Communication Management (ara::com) bildet das Rückgrat der serviceorientierten Architektur (SOA) in der AUTOSAR Adaptive Platform und entkoppelt Anwendungslogik über das Proxy-Skeleton-Muster von konkreten Übertragungsprotokollen (SWS_CommunicationManagement S. 55, ARAComAPI S. 1). Aus formalen Schnittstellenbeschreibungen generierte Proxy-Klassen auf Konsumentenseite und Skeleton-Klassen auf Providerseite stellen Methoden, Events und Fields über typsichere C++-APIs bereit ([SWS_CM_00130], [SWS_CM_00131]).
Die Bereitstellung und dynamische Suche von Diensten wird über Service Discovery abgewickelt (SWS_CommunicationManagement S. 67). Ein Provider bietet seinen Dienst über OfferService() an ([SWS_CM_00101]), während Konsumenten passende Instanzen synchron via FindService() oder asynchron mittels StartFindService() ermitteln ([SWS_CM_00122], [SWS_CM_00123]). Dabei können Instanzen über ara::core::InstanceSpecifier modellbasiert adressiert und zur Laufzeit in konkrete ara::com::InstanceIdentifier aufgelöst werden ([SWS_CM_00118], [SWS_CM_00622]).
Sequenzdiagramm: Ablauf von Service Offering, asynchroner Suche und Proxy-Erzeugung. Quellen: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces S. 16
Für die Datenübertragung unterstützt ara::com Request-Response-Methoden über ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]) sowie Publish-Subscribe-Muster für Events und Fields (AUTOSAR_EXP_ARAComAPI S. 68). Abonnenten registrieren sich über Subscribe() ([SWS_CM_00141]) und lesen eingehende Daten über GetNewSamples() aus ([SWS_CM_00701]). Zur Performanzsteigerung stellt der Provider Daten über Allocate() bereit und übergibt die Eigentümerschaft per Zero-Copy via Send() ([SWS_CM_90437], [SWS_CM_90438]).
Zur Absicherung der Übertragung integriert die Plattform End-to-End-Schutz (E2E), kryptografische Authentifizierung (SecOC) über Freshness Value Management (FVM) sowie Signal-to-Service-Translation für klassische Netzwerke ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement S. 222). Fehlerzustände werden standardisiert über typsichere Fehlerdomänen wie ComErrorDomain und ComE2EErrorDomain signalisiert ([SWS_CM_10432], [SWS_CM_10474]). Bricht die Verbindung zu einem Service ab, wechselt der Status des Proxies auf kSubscriptionPending; nach erneuter Verfügbarkeit aktualisiert die Middleware die interne Adressierung transparent, sodass die Kommunikation ohne Neuinstanziierung des Proxies fortgesetzt wird (ARAComAPI S. 32).
Rolle und Systemarchitektur der serviceorientierten Kommunikation
Das Functional Cluster Communication Management (ara::com) bildet das informationstechnische Rückgrat der AUTOSAR Adaptive Platform und realisiert die serviceorientierte Kommunikation (Service-Oriented Architecture, SOA) zwischen isolierten Anwendungs-Prozessen sowie über Steuergerätegrenzen hinweg (SWS_CommunicationManagement S. 55). Kernprinzip ist das strikte Proxy-Skeleton-Entwurfsmuster (ARAComAPI S. 1): Aus formalen Software-Schnittstellenbeschreibungen (Service Interfaces) generiert ein modellbasierter Codegenerator typisierte Proxy-Klassen für Service-Konsumenten und Skeleton-Klassen für Service-Provider ([SWS_CM_00130], [SWS_CM_00131]). Die Applikationslogik interagiert ausschließlich mit diesen Abstraktionen, während protokollspezifische Bindings wie SOME/IP, IPC oder DDS sowie deren Serialisierung erst zur Integrations- und Deploymentzeit angebunden werden (AUTOSAR_AP_EXP_ARAComAPI S. 124).
Zur Erfüllung von Plattformanforderungen kooperiert ara::com eng mit weiteren Funktionsclustern (SWS_CommunicationManagement S. 34). Zur Laufzeit überwacht Execution Management den Prozesslebenszyklus, während das Identity and Access Management (IAM) über richtlinienbasierte Zugriffsprüfungen (Policy Decision Point) unautorisierte Interaktionen auf Method-, Event- und Field-Ebene abwehrt (SWS_CommunicationManagement S. 215). Zudem werden Sicherheitsereignisse direkt an den EventReporter des Intrusion Detection System Managers (IdSM) gemeldet (SWS_CommunicationManagement S. 34).
Kontextdiagramm: Einbettung von ara::com und Entkopplung der Applikationsebenen über Bindings. Quellen: SWS_CommunicationManagement S. 55, ARAComAPI S. 1
Dienstfindung und Instanziierung über Proxies und Skeletons
Die dynamische Dienstvermittlung (Service Discovery) regelt das Zustandekommen lokaler und verteilter Kommunikationsbeziehungen (SWS_CommunicationManagement S. 67). Ein Service-Provider signalisiert seine Verfügbarkeit durch den Aufruf von OfferService() am Skeleton ([SWS_CM_00101]). Wird der Dienst beendet oder die Bereitstellung entzogen, zieht StopOfferService() das Angebot zurück ([SWS_CM_00111]). Konsumenten ermitteln passende Service-Instanzen synchron über FindService() oder asynchron über StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI S. 103). Letzteres registriert einen FindServiceHandler, der bei jeder Änderung der Instanzlandschaft benachrichtigt wird, bis die Suche mittels StopFindService() explizit beendet wird ([SWS_CM_00125], [SWS_CM_00383]).
Um Quellcode von festen Netzwerk- und Instanz-IDs zu entkoppeln, gestattet die Schnittstelle die Adressierung über abstrakte Modellpfade mittels ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI S. 124). Die Middleware löst diese Spezifizierer über das hinterlegte Service Instance Manifest in konkrete ara::com::InstanceIdentifier auf ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI S. 1). Ein gefundener Dienst wird als typisierter Deskriptor (HandleType) in einem ServiceHandleContainer bereitgestellt ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces S. 16). Über die statische Fabrikmethode Proxy::Create() oder den Konstruktor erzeugt der Konsument eine gebundene Proxy-Instanz zur weiteren Funktionsnutzung ([SWS_CM_10438], [SWS_CM_00131]).
Sequenzdiagramm: Ablauf von Service Offering, asynchroner Suche und Proxy-Erzeugung. Quellen: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces S. 16
Interaktionsmuster: Methodenaufrufe und asynchrone Verarbeitung
Methodenaufrufe bilden das synchrone und asynchrone Request-Response-Paradigma ab. Der Client löst Methoden über den Funktionsaufruf-Operator operator() am Proxy aus ([SWS_CM_00196]). Als Rückgabetyp dient standardmäßig ein ara::core::Future, welcher das Ergebnis oder einen Fehlerzustand kapselt ([SWS_CM_00191], ARAComAPI S. 1). Der Konsument entscheidet flexibel über die Synchronisation: durch blockierendes Abrufen via get(), zeitüberwachtes Warten via wait_for() bzw. wait_until() oder durch Registrierung ereignisbasierter Callback-Routinen mittels then() (ARAComAPI S. 1). Für reine unidirektionale Benachrichtigungen ohne Rückmeldung existieren Fire-and-Forget-Methoden mit void-Rückgabe ([SWS_CM_90434], [SWS_CM_90435]).
Auf der Provider-Seite definiert der MethodCallProcessingMode die Ausführungsstrategie für eingehende Aufrufe ([SWS_CM_00301], [SWS_CM_00130]). Im ereignisgesteuerten Modus (kEvent bzw. kEventSingleThread) erfolgt der Methodenaufruf sofort innerhalb eines von der Middleware verwalteten Worker-Threads (AUTOSAR_SWS_CommunicationManagement S. 60). Im Polling-Modus (kPoll) steuert die Applikation die Verarbeitungszeitpunkte deterministisch selbst, indem sie regelmäßig ProcessNextMethodCall() aufruft ([SWS_CM_00199], EXP_SWArchitecture S. 68). Die Methodenimplementierung erzeugt das Ergebnis intern über ein ara::core::Promise und liefert das verknüpfte Future zurück (ARAComAPI S. 1).
Sequenzdiagramm: Methodenaufruf zwischen Proxy und Skeleton unter kPoll- und kEvent-Dispatching. Quellen: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement S. 60
Ereignis- und Feldkommunikation im Publish-Subscribe-Muster
Die Verteilung kontinuierlicher Datenströme und Zustandsänderungen erfolgt über Events und Fields im Publish-Subscribe-Muster (SWS_CommunicationManagement S. 67). Ein aktiver Subscriber meldet sein Empfangsinteresse über Subscribe() unter Angabe der maximal vorzuhaltenden Sample-Anzahl (maxSampleCount) an ([SWS_CM_00141], [SWS_CM_12002]). Der Abonnementstatus wird über GetSubscriptionState() abgefragt oder asynchron über Callbacks via SetSubscriptionStateChangeHandler() überwacht ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). Das Beenden des Abonnements erfolgt über Unsubscribe() ([SWS_CM_00151]).
Der Datenempfang kann ereignisgetrieben über SetReceiveHandler() oder durch periodisches Auslesen des Empfangspuffers erfolgen ([SWS_CM_00181], [SWS_CM_11356]). Mit GetNewSamples() übergibt der Konsument ein Funktionsobjekt (Lambda), das für jedes eingetroffene Sample mit einem typisierten SamplePtr aufgerufen wird ([SWS_CM_00701], [SWS_CM_11610]). Zur Vermeidung von Kopieraufwänden (Zero-Copy) stellt das Skeleton Speicher über Allocate() bereit und sendet den typisierten Zeiger SampleAllocateePtr unter vollständigem Eigentumsübergang via Send() an die Übertragungsschicht ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI S. 63, ARAComAPI S. 1).
Ein Field erweitert das Event-Konzept um Getter- und Setter-Semantik (AUTOSAR_EXP_ARAComAPI S. 68). Konsumenten lesen das Field über Get() oder schreiben es über Set() ([SWS_CM_00112], [SWS_CM_00113]). Serverseitig werden diese Anfragen mit RegisterGetHandler() bzw. RegisterSetHandler() bedient ([SWS_CM_00114], [SWS_CM_00116]). Aktualisiert der Server den Zustand über Update(), fungiert das Field automatisch als Notifier und verteilt die Änderung an alle registrierten Abonnenten ([SWS_CM_00119], ARAComAPI S. 1).
Sequenzdiagramm: Zero-Copy-Allokation, Event-Publishing, Subscription und GetNewSamples-Konsum. Quellen: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI S. 63
Absicherung, Dienstübersetzung und Plattformintegration
Für sicherheitsrelevante und deterministische Datenflüsse integriert ara::com End-to-End-Absicherung (E2E) und Authentifizierung gemäß AUTOSAR-Standards (AUTOSAR_AP_TR_SystemTests S. 132). Über GetProfileCheckStatus() und GetE2EStateMachineState() können Konsumenten den Integritäts- und Validierungsstatus empfangener Daten prüfen ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). Serverseitig registriert die Applikation Fehlerbehandlungsroutinen über SetTransportFaultConditionHandler(), um auf E2E- und Transportdefekte auf Methodenebene standardisiert zu reagieren ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture S. 68).
Die kryptografische Integrität und Authentizität externer Botschaften wird durch Secure Onboard Communication (SecOC) gewährleistet (SWS_CommunicationManagement S. 222). Hierzu bindet die Middleware eine austauschbare Freshness Value Management Bibliothek (FVM) ein, die über GetRxFreshness(), GetTxFreshness() und Initialize() Freshness-Werte verwaltet ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement S. 226). Diagnose- und Sicherheitsfunktionen überwachen oder steuern die Verifikation über spezifische Schnittstellen wie SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture S. 70).
Zur Interoperabilität mit der AUTOSAR Classic Platform unterstützt ara::com die signalbasierte Kommunikation (Signal-to-Service Translation) (SWS_CommunicationManagement S. 146, TPS_ManifestSpecification S. 476). Gemäß [SWS_CM_10174] und [SWS_CM_80001] können klassische Signal-IPDUs und SOME/IP-Nachrichten über denselben Socket transportiert werden. Liegt eine signalbasierte SecOC-Konfiguration vor, liest die Middleware die Schutzparameter direkt aus dem PDU-Triggering des Manifests ([SWS_CM_11346], SWS_CommunicationManagement S. 228).
Aktivitätsdiagramm: E2E- und SecOC-Absicherungspipeline eingehender Nachrichten. Quellen: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement S. 222
Verhalten im Fehlerfall
Das Fehlermanagement von ara::com basiert auf typsicheren Fehlerdomänen und Return-Codes des AUTOSAR-Core-Frameworks ([SWS_CM_11334], [SWS_CM_11335]). Fehler der allgemeinen Kommunikationsschicht werden in der ComErrorDomain zusammengefasst und über den Enumerator ComErrc codiert ([SWS_CM_10432]). Bei E2E-Überprüfungsfehlern signalisiert die ComE2EErrorDomain über den Enumerationswert ComE2EErrc spezifische Prüffehler wie Checksummenabweichungen oder ungültige Zähler ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). Für SecOC-Freshness-Fehler existiert analog die ComSecOcFvmErrorDomain mit ComSecOcFvmErrc ([SWS_CM_12521], [SWS_CM_12522]).
Tritt während der Laufzeit ein Verbindungsabbruch auf, wechselt der Abonnementstatus des Proxies von kSubscribed auf kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI S. 32). Methodenaufrufe schlagen in dieser Phase mit einem Fehler fehl. Kehrt der Service-Provider anschließend über Service Discovery zurück, aktualisiert die Middleware die interne Adressierung des Proxies transparent, ohne dass der Konsument das Proxy-Objekt neu instanziieren muss; nach erfolgreicher Re-Synchronisation kehrt der Status automatisch auf kSubscribed zurück (ARAComAPI S. 32). Für zeitliche Fristen und Deadline-Überwachung (Deadline Monitoring) ist gemäß Systemspezifikation die Applikationssoftware selbst zuständig (TPS_ManifestSpecification S. 504).
Zustandsdiagramm: Lebenszyklus und Verbindungszustände einer Proxy-Instanz bei Verfügbarkeitsänderungen des Providers. Quellen: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI S. 32
Weiterführende Detailbelege
Die wesentlichen Anforderungen und Systemschnittstellen gliedern sich wie folgt in die AUTOSAR-Spezifikationen ein:
- Service-Lebenszyklus und Discovery: Dienstbereitstellung und Suchmechanismen basieren auf [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] und [SWS_CM_00123], detailliert im Software-Architekturleitfaden (ARAComAPI S. 103).
- Interaktionsparadigmen: Methoden und asynchrone Zukunftswerte sind in [SWS_CM_00191] und [SWS_CM_00196] normiert; Event-Abonnements und Sample-Übertragungen folgen [SWS_CM_00141], [SWS_CM_00701] und [SWS_CM_90437] (SWS_CommunicationManagement S. 67).
- Sicherheit und Serialisierung: Absicherungskonzepte für E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]) und Signal-to-Service-Translation ([SWS_CM_10174]) regeln den systemweiten Datenaustausch (SWS_CommunicationManagement S. 146, SWS_CommunicationManagement S. 222).
- Manifest- und Typdefinitionen: Die Abbildung strukturierter Datentypen, optionaler Felder und Instanzspezifizierer ist in der Manifestspezifikation verankert (TPS_ManifestSpecification S. 161, TPS_ManifestSpecification S. 458).
Dieser Leitfaden wurde durch einen KI-Kurations-Assistenten auf Basis des AUTOSAR Adaptive Release R25-11 erstellt.
Themenkarte
ara::com
22Für dieses Release liegen keine Elementdaten vor
<SI-Namespace>::proxy
Service Interface Proxy
<SI-Namespace>::proxy::fields
Service proxy Field class, one for each Field defined in the ServiceInterface in the role field.
<SI-Namespace>::proxy::methods
Service proxy fire-and-forget method class, one for each ClientServerOperation ( ClientServerOperation.fireAndForget==TRUE) defined in the S
Service proxy method class, one for each ClientServerOperation ( ClientServerOperation.fireAndForget ==FALSE) defined in the ServiceInterfac
<SI-Namespace>::proxy::triggers
Service proxy Trigger class, one for each Trigger defined in the ServiceInterface in the role trigger.
<SI-Namespace>::skeleton
Service skeleton class
<SI-Namespace>::skeleton::fields
Service skeleton Field class, one for each Field defined in the ServiceInterface in the role field.
<SI-Namespace>::skeleton::triggers
Service skeleton Trigger class, one for each Trigger defined in the ServiceInterface in the role trigger.
apext::com::secoc
Defines a class representing the SecOc Freshness Value Manager error domain
erbt von ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the SecOc Freshness Value Manager
erbt von ara::core::Exception
A container to hold the length of freshness value in bits and the freshness value itself
A freshness value management interface to be implemented by the OEM/stack vendor
Returns a reference to the apext::com::secoc::ComSecOcFvmErrorDomain object
constexpr const ara::core::ErrorDomain & GetComSecOcFvmErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (apext::com::secoc::Com SecOcFvmErrc errorCode, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the apext::com::secoc::ComSecOcFvmErrorDomain
enum class ComSecOcFvmErrc : ara::core::ErrorDomain::CodeType {...};ara::com
Defines a class representing the Communication error domain.
erbt von ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the API.
erbt von ara::core::Exception
The exact definition of ara::com::FindServiceHandle is Communication Management implementation specific
Unique identifier of a specific AdaptivePlatformServiceInstance, to distinguish different instances of exactly the same service
Emulates a std::unique_ptr to an event sample. The ara::com::SamplePtr behaves as a std::unique_ptr as long as the event/ field is subscrib ≙ std::unique_ptr
Specifies a Service Identifier The exact type may be overridden by the Communication Management software provider
Specifies a Service Version
Returns a reference to the ara::com::ComErrorDomain object
constexpr const ara::core::ErrorDomain & GetComErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (ara::com::ComErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the ara::com::ComErrorDomain
enum class ComErrc : ara::core::ErrorDomain::CodeType {...};Processing modes for the service implementation.
enum class MethodCallProcessingMode : std::uint8_t {...};The state of the service from GetServiceState()
enum class ServiceState : std::uint8_t {...};The subscription state of an event.
enum class SubscriptionState : std::uint8_t {...};Callback function invoked if new event data arrives for an event. The event receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using EventReceiveHandler = std::function<void()>;Callback function invoked if a new notification arrives for a field. The field receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using FieldReceiveHandler = std::function<void()>;Callback function invoked if service availability changes. It takes as input parameter a handle container containing handles for all matching service instances and a ara::com:: FindServiceHandle which can be used to invoke StopFindService() from within the ara::com::FindServiceHandler.
using FindServiceHandler = std::function<void(ServiceHandle Container<T>, FindServiceHandle)>;Holds a list of ara::com::InstanceIdentifiers. The assigned data type is allowed to be changed by the Communication Management software provider, but must adhere to [container.requirements.general] and [sequence.reqmts] requirements as per [30] A ara::core::Vector ([SWS_CORE_01301]) for example fulfills these requirements.
using InstanceIdentifierContainer = ara::core::Vector<Instance Identifier>;Pointer to an allocated (by Communication Management) data sample. The implementation is allowed to be changed by the Communication Management software provider.
using SampleAllocateePtr = std::unique_ptr<T>;Holds a list of service handles and is used as a return value of any of the FindService() methods) • [SWS_CM_00122] • [SWS_CM_00622] . The assigned data type is allowed to be changed by the Communication Management software provider, but must adhere to [container.requirements.general] and [sequence.reqmts] requirements as per [30]. A ara::core::Vector ([SWS_CORE_ 01301]) for example fulfills these requirements.
using ServiceHandleContainer = ara::core::Vector<T>;Functor used as input arguments for any of the SetServiceStateChangeHandler() methods: • [SWS_CM_01074] • [SWS_CM_01076]
using ServiceStateHandler = std::function<void(ServiceState)>;Callback function invoked if ara::com::SubscriptionState of an event has changed.
using SubscriptionStateChangeHandler = std::function<void(Subscription State)>;A function wrapper for the handler function that gets called in case a new trigger arrives for an event. The trigger receiver must provide the function implementation which is not required to be re-entrant. Usage of std::function is recommended but not mandatory. ≙ std::function
using TriggerReceiveHandler = std::function<void()>;ara::com::e2e
Defines a class representing the E2E error domain
erbt von ara::core::ErrorDomain
Defines a class for exceptions to be thrown by the E2E APIs
erbt von ara::core::Exception
Returns a reference to the ara::com::e2e::ComE2EErrorDomain object
constexpr const ara::core::ErrorDomain & GetComE2EErrorDomain () noexcept;Creates an instance of ara::core::ErrorCode
constexpr ara::core::ErrorCode MakeErrorCode (ara::com::e2e::ComE2 EErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept;Defines the error codes for the ara::com::e2e::ComE2EErrc
enum class ComE2EErrc : ara::core::ErrorDomain::CodeType {...};The result of the check of a single ara::com::SamplePtr
enum class ProfileCheckStatus : std::uint8_t {...};The state of the E2E supervision after the most recent check of a received sample of the event. If ara::com::e2e::SMState == kValid, and the ara::com::SamplePtr:: GetProfileCheckStatus did not result in an Error then, the last checked sample can be used.
enum class SMState : std::uint8_t {...};Defines the TransportFaultCondition which represent a single transport-related fault event
enum class TransportFaultCondition : std::uint8_t {...};Handler type to be called when one or more (determined by the value of the std::size_t) fault conditions are detected ≙ std::size_t
using TransportFaultConditionHandler = std::function<void(Transport FaultCondition, std::size_t)>;ara::com::runtime
Translates an ara::core::InstanceSpecifier to a ara::com:: InstanceIdentifierContainer. The length/size of the ara::com:: InstanceIdentifierContainer is relative to the number of matches.
ara::core::Result< ara::com::InstanceIdentifierContainer > Resolve InstanceIDs (ara::core::InstanceSpecifier metaModelIdentifier) noexcept;Service-Interfaces
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Als ara::com-Dienst modellierte Schnittstelle; Methoden/Felder werden über generierte Proxies/Skeletons aufgerufen (Parameterrichtung IN/OUT).
Verwandte Komponenten in anderen Universen
function: 179 class: 20 type alias: 20 variable: 13 enumeration: 10 struct: 4 service method: 2 header file: 1 service event: 1
Namespaces
- <SI-Namespace>::proxy 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::fields 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::methods 2 Klassen, 0 freie Funktionen
- <SI-Namespace>::proxy::triggers 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton::fields 1 Klassen, 0 freie Funktionen
- <SI-Namespace>::skeleton::triggers 1 Klassen, 0 freie Funktionen
- apext::com::secoc 4 Klassen, 2 freie Funktionen
- ara::com 7 Klassen, 2 freie Funktionen
- ara::com::e2e 2 Klassen, 2 freie Funktionen
- ara::com::runtime 0 Klassen, 1 freie Funktionen
Service-Interfaces (ara::com-modelliert)
- VerificationStatus 1 Mitglieder
- VerificationStatusConfigurationByDataId 1 Mitglieder
- VerificationStatusConfigurationByFreshnessId 1 Mitglieder
UML-Klassendiagramm des Moduls
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-medium· 2026-10-13