service interface VerificationStatus

Das Service-Interface VerificationStatus wird vom Functional Cluster Communication Management bereitgestellt, um interessierte Anwendungen über ein zentrales Service-Ereignis asynchron mit Verifikationsdaten im Format VerificationStatusContainer zu versorgen [SWS_CM_11367]. Konsumenten abonnieren das Ereignis über einen Client-Proxy, während steuernde Filterungen über separate Konfigurationsschnittstellen vorgenommen werden können. Als wesentliche Randbedingung weist das Interface im Release R25-11 den Status DRAFT auf und enthält keine synchronen Methoden oder spezifischen Application Errors [SWS_CM_11280].

mehr ›

Rolle und Systemkontext der Service-Schnittstelle

Das Service-Interface VerificationStatus wird innerhalb der AUTOSAR Adaptive Platform vom Functional Cluster Communication Management (CM) bereitgestellt AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 „Provided Ports“. Die Spezifikation definiert hierfür den gleichnamigen Provided Port VerificationStatus, über den das Kommunikationsmanagement als Service-Provider auftritt [SWS_CM_11367]. Als Client-Server- bzw. Service-Schnittstelle richtet sich die Definition an adaptive Anwendungen und Plattformkomponenten [SWS_CM_11280]. Die funktionale Rolle besteht in der Verteilung von Verifikationszuständen über das Kommunikations-Framework, wobei das Functional Cluster CM das Skeleton instanziiert und abnehmende Einheiten als Service-Proxys fungieren AUTOSAR_AP_SWS_CommunicationManagement §9.2.2 „Client -Server Interfaces“. Interpretation: Vermutlich dient diese Schnittstelle primär der Sicherheits- und Integritätsüberwachung, indem Verifikationsergebnisse empfangener Kommunikationsdaten an Sicherheitsmonitore oder Diagnosekomponenten gemeldet werden. Frage Q-4ff3779da80934a6 (offen)

Im Gesamtsystem ist die Schnittstelle in ein Gefüge ergänzender Konfigurationsschnittstellen eingebettet AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 „Provided Ports“. Das Cluster CM stellt parallel die Ports VerificationStatusConfigurationByDataId [SWS_CM_11369] und VerificationStatusConfigurationByFreshnessId [SWS_CM_11368] bereit, welche an die Service-Interfaces VerificationStatusConfigurationByDataId [SWS_CM_11282] sowie VerificationStatusConfigurationByFreshnessId [SWS_CM_11281] gekoppelt sind. Während VerificationStatus die laufenden Statusmeldungen publiziert, steuern die flankierenden Schnittstellen die Zuordnungen nach Daten- oder Frische-Kennungen [SWS_CM_11280].

Methoden, Ereignisse und Felder

Das Service-Interface VerificationStatus beinhaltet das zentrale Service-Event VerificationStatus in Version 1.0 [SWS_CM_10048]. Das Ereignis kapselt den Datentyp VerificationStatusContainer und dient dem standardisierten Austausch von Verifikationsdaten [SWS_CM_10048]. Die Kommunikation folgt dabei dem klassischen Publish/Subscribe-Paradigma von ara::com: Das Functional Cluster CM versendet die Statusaktualisierungen asynchron an alle registrierten Empfänger, sobald neue Verifikationsereignisse verarbeitet wurden [SWS_CM_11280].

Direkte synchrone Methoden oder Service-Felder mit Notifier-Semantik sind im Interface VerificationStatus nicht definiert [SWS_CM_11280]. Die Informationsübermittlung erfolgt folglich vollständig entkoppelt über das spezifizierte Ereignis [SWS_CM_10048]. Zusätzliche steuernde Eingriffe, beispielsweise das Selektieren bestimmter Datenquellen, werden über die separaten Konfigurationsschnittstellen des Moduls abgewickelt [SWS_CM_11282], [SWS_CM_11281].

Lebenszyklus, Sitzungsabläufe und Zustandsabhängigkeiten

Der Interaktionsablauf beginnt auf Consumer-Seite mit dem Auffinden des Dienstes und der Instanziierung des Proxys für den Port VerificationStatus AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 „Provided Ports“, [SWS_CM_11367]. Anschließend initiiert der Consumer das Abonnement für das Service-Event VerificationStatus [SWS_CM_10048]. Nach erfolgreicher Bestätigung des Abonnements übermittelt das CM-Skeleton Statusaktualisierungen im laufenden Betrieb asynchron an den Consumer [SWS_CM_11280].

Interpretation: Das Eintreffen von Statusereignissen dürfte voraussetzen, dass das CM-Cluster zuvor über die Ports VerificationStatusConfigurationByDataId oder VerificationStatusConfigurationByFreshnessId bezüglich der zu prüfenden Botschaften konfiguriert wurde [SWS_CM_11369], [SWS_CM_11368]. Frage Q-8740e3935265ddcd (offen) Nach Abschluss dieser Konfigurationsphase fließen die Ereignisse kontinuierlich und zustandsabhängig bei jeder durchgeführten Verifikation [SWS_CM_10048].

Sequenzdiagramm: Ablauf beim Abonnement und Empfang des Ereignisses VerificationStatus. Quellen: [SWS_CM_11367], [SWS_CM_11280], [SWS_CM_10048].

Fehlerbehandlung und Spezifikationsstatus

Da der Informationsfluss rein über das asynchrone Service-Event abgebildet wird, spezifiziert VerificationStatus keine spezifischen ApplicationErrors oder modulspezifischen Fehlerdomänen [SWS_CM_10048]. Etwaige Fehler bei der Bereitstellung oder Übertragung werden durch die allgemeine Fehler- und Event-Verwaltung der ara::com-Laufzeitumgebung behandelt [SWS_CM_11280]. Inhaltliche Verifikationsfehlschläge empfangener Botschaften werden innerhalb der Nutzlast des VerificationStatusContainer signalisiert [SWS_CM_10048].

Für die Systemintegration ist zu beachten, dass sowohl der Port VerificationStatus [SWS_CM_11367] als auch das Service-Interface [SWS_CM_11280] und die zugehörigen Konfigurationsports [SWS_CM_11369], [SWS_CM_11368] im Release R25-11 mit dem Status DRAFT versehen sind AUTOSAR_AP_SWS_CommunicationManagement §9.2.2 „Client -Server Interfaces“. Interpretation: Künftige Revisionen der Spezifikation dürften daher feinere Fehlerdiagnosen oder weiterführende Fehlerbehandlungsmechanismen für die Schnittstelle definieren. Frage (offen)