service interface VerificationStatusConfigurationByDataId

The service interface VerificationStatusConfigurationByDataId, which is in DRAFT status, is provided by the Functional Cluster Communication Management to dynamically configure the SecOC verification behavior for specific data IDs ([SWS_CM_11369]). Via the method VerifyStatusOverride, authorized applications can force the acceptance, discarding, or skipping of messages and specify a defined verification result ([SWS_CM_10050]). The method invocation is acknowledged synchronously with Fire & Forget false, whereby a restriction to a fixed number of consecutive messages can also be specified via a counter parameter.

more ›

1. Role and system context of the service interface

The service interface VerificationStatusConfigurationByDataId is provided by the Functional Cluster Communication Management (CM) as a service port ([SWS_CM_11369]). In the AUTOSAR Adaptive service architecture, communication management assumes the role of the service provider (skeleton), while authorized functional applications interact as consumers via the generated proxy (AUTOSAR_AP_SWS_CommunicationManagement §8.x “Definition of Port VerificationStatusConfigurationByDataId”). The primary task of this interface is to specifically configure and override the cryptographic verification behavior of Secure Onboard Communication (SecOC) for a passed message identifier (dataID) ([SWS_CM_10050]).

The interface supplements the regular verification status reporting service, through which the system forwards each verification result to applications ([SWS_CM_11278]). Consumers of the configuration interface are typically expected to be specialized security management systems, Intrusion Detection Systems (IDS), or test and diagnostic applications that dynamically control and monitor the discarding or forwarding of messages (AUTOSAR_AP_SWS_CommunicationManagement §9.1 “SecOC VerificationStatus”). Question Q-93c34e1f19b92c49 (open) In this way, Communication Management is enabled to selectively override verification results during runtime ([SWS_CM_11279]).

2. Methods, events, and fields

The service specification contains neither events nor fields, but exclusively defines a synchronous or feedback-capable client-server method ([SWS_CM_10050]):

• VerifyStatusOverride: Forces a specific SecOC behavior upon receiving messages (accepting or discarding with or without performing authenticator verification) and allows setting a defined result for VerificationStatusResult ([SWS_CM_10050]).

The method has version 1.0 and is specified with Fire & Forget false ([SWS_CM_10050]). In the C++ programming model of ara::com, the invocation therefore typically returns a ara::core::Future confirming the completion of the configuration (interpretation). Question Q-44d3566c154670c9 (open) The method defines three input parameters ([SWS_CM_10050]):

• dataID (direction IN, type uint16_t): Unique identifier of the message for which the override is to be applied ([SWS_CM_10050]).
• overrideStatus (direction IN, type OverrideStatus): Enumeration value specifying whether verification is performed, whether the message is discarded or forwarded, and for what duration the override remains active ([SWS_CM_10050]).
• numberOfMessagesToOverride (direction IN, type uint8_t): Number of sequential verification operations to be overridden. This counter is only considered if overrideStatus is set to kSecOcOverrideDropUntilLimit, kSecOcOverrideSkipUntilLimit, or kSecOcOverridePassUntilLimit ([SWS_CM_10050]).

3. Lifecycle, session flows, and state dependencies

The definition of service port VerificationStatusConfigurationByDataId is designated with the status DRAFT in release R25-11 ([SWS_CM_11369]). After startup of the Functional Cluster Communication Management, it provides the skeleton service, whereupon interested consumers resolve and bind the instance via service discovery (AUTOSAR_AP_SWS_CommunicationManagement §8.x “Definition of Port VerificationStatusConfigurationByDataId”).

Sequence diagram: Flow of overriding the verification status via the method VerifyStatusOverride. Sources: [SWS_CM_10050], [SWS_CM_11279], AUTOSAR_AP_SWS_CommunicationManagement §9.1 “SecOC VerificationStatus”.

Normally, a failed authenticator verification in SecOC causes the affected message to be discarded (AUTOSAR_AP_SWS_CommunicationManagement §9.1 “SecOC VerificationStatus”). However, as soon as VerifyStatusOverride has been successfully called, the configured setting takes effect immediately for all subsequent messages of the specified dataID ([SWS_CM_10050]). Depending on parameter overrideStatus, the manipulation either remains active permanently or ends automatically as soon as the number of messages defined in counter numberOfMessagesToOverride has been processed ([SWS_CM_10050]).

4. Error handling and application errors

Since VerifyStatusOverride does not exhibit fire-and-forget behavior, the calling application receives explicit feedback on the outcome of the configuration request ([SWS_CM_10050]). Specific application errors or error codes are not declared for this service interface in the standard; any invocation errors are therefore likely reported via general error domains of the ara::com infrastructure ([SWS_CM_10050]). Question Q-d1e549f2415ac403 (open)

Functionally, the service itself serves as a central instrument for application-side error handling: By enabling a specific VerificationStatusResult to be forced, error handling routines in the application can be stimulated and validated ([SWS_CM_10050]). This enables an IDS or security management system to selectively run simulated attacks or faulty transmissions and test appropriate dynamic countermeasures in the overall system (AUTOSAR_AP_SWS_CommunicationManagement §9.1 “SecOC VerificationStatus”).