service interface VerificationStatus

The service interface VerificationStatus is provided by the Communication Management Functional Cluster to asynchronously supply interested applications with verification data in the format VerificationStatusContainer via a central service event [SWS_CM_11367]. Consumers subscribe to the event via a client proxy, while controlling filter operations can be carried out via separate configuration interfaces. As an essential constraint, the interface has the status DRAFT in release R25-11 and contains no synchronous methods or specific Application Errors [SWS_CM_11280].

more ›

Role and system context of the service interface

The service interface VerificationStatus is provided within the AUTOSAR Adaptive Platform by the Communication Management (CM) Functional Cluster AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 “Provided Ports”. For this purpose, the specification defines the provided port VerificationStatus of the same name, via which Communication Management acts as a service provider [SWS_CM_11367]. As a client-server or service interface, the definition is aimed at adaptive applications and platform components [SWS_CM_11280]. The functional role consists in distributing verification states via the communication framework, where the CM Functional Cluster instantiates the skeleton and consuming entities act as service proxies AUTOSAR_AP_SWS_CommunicationManagement §9.2.2 “Client -Server Interfaces”. Interpretation: Presumably, this interface primarily serves safety and integrity monitoring by reporting verification results of received communication data to safety monitors or diagnostic components. Question Q-4ff3779da80934a6 (open)

In the overall system, the interface is embedded in a structure of complementary configuration interfaces AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 “Provided Ports”. In parallel, the CM cluster provides the ports VerificationStatusConfigurationByDataId [SWS_CM_11369] and VerificationStatusConfigurationByFreshnessId [SWS_CM_11368], which are coupled to the service interfaces VerificationStatusConfigurationByDataId [SWS_CM_11282] and VerificationStatusConfigurationByFreshnessId [SWS_CM_11281]. While VerificationStatus publishes the ongoing status messages, the flanking interfaces control the mappings by data or freshness identifiers [SWS_CM_11280].

Methods, events, and fields

The service interface VerificationStatus includes the central service event VerificationStatus in version 1.0 [SWS_CM_10048]. The event encapsulates the data type VerificationStatusContainer and is used for the standardized exchange of verification data [SWS_CM_10048]. Communication follows the classic publish/subscribe paradigm of ara::com: The CM Functional Cluster sends the status updates asynchronously to all registered receivers as soon as new verification events have been processed [SWS_CM_11280].

Direct synchronous methods or service fields with notifier semantics are not defined in the interface VerificationStatus [SWS_CM_11280]. Information transmission thus takes place completely decoupled via the specified event [SWS_CM_10048]. Additional controlling interactions, such as selecting specific data sources, are handled via the separate configuration interfaces of the module [SWS_CM_11282], [SWS_CM_11281].

Lifecycle, session sequences, and state dependencies

The interaction sequence begins on the consumer side with finding the service and instantiating the proxy for the port VerificationStatus AUTOSAR_AP_SWS_CommunicationManagement §9.2.1 “Provided Ports”, [SWS_CM_11367]. The consumer then initiates the subscription for the service event VerificationStatus [SWS_CM_10048]. After successful confirmation of the subscription, the CM skeleton transmits status updates asynchronously to the consumer during ongoing operation [SWS_CM_11280].

Interpretation: The arrival of status events likely requires that the CM cluster was previously configured via the ports VerificationStatusConfigurationByDataId or VerificationStatusConfigurationByFreshnessId regarding the messages to be verified [SWS_CM_11369], [SWS_CM_11368]. Question Q-8740e3935265ddcd (open) After this configuration phase is completed, the events flow continuously and state-dependently with each verification performed [SWS_CM_10048].

Sequence diagram: Sequence during subscription and reception of the VerificationStatus event. Sources: [SWS_CM_11367], [SWS_CM_11280], [SWS_CM_10048].

Error Handling and Specification Status

Since the information flow is mapped purely via the asynchronous service event, VerificationStatus does not specify any specific ApplicationErrors or module-specific error domains [SWS_CM_10048]. Any errors during provisioning or transmission are handled by the general error and event management of the ara::com runtime environment [SWS_CM_11280]. Verification failures regarding the content of received messages are signaled within the payload of the VerificationStatusContainer [SWS_CM_10048].

For system integration, it should be noted that both the port VerificationStatus [SWS_CM_11367] and the service interface [SWS_CM_11280] as well as the associated configuration ports [SWS_CM_11369], [SWS_CM_11368] are marked with the status DRAFT in release R25-11 AUTOSAR_AP_SWS_CommunicationManagement §9.2.2 “Client -Server Interfaces”. Interpretation: Future revisions of the specification are therefore likely to define finer-grained error diagnostics or extended error-handling mechanisms for the interface. Question (open)