service interface VerificationStatusConfigurationByFreshnessId

In communication management, the service interface VerificationStatusConfigurationByFreshnessId serves to selectively manipulate the verification behavior of SecOC for specific freshness values ([SWS_CM_10049]). Via the method VerifyStatusOverride, applications can have messages accepted, skipped, or dropped regardless of the authentication result. The method operates with acknowledged feedback and evaluates the specified message count exclusively in specific limit states ([SWS_CM_10049]).

more ›

Role and system context of the service interface

In communication management (com) of the AUTOSAR Adaptive Platform, the service interface VerificationStatusConfigurationByFreshnessId provides a functional interface with which the verification behavior of SecOC (Secure Onboard Communication) can be controlled in a targeted manner ([SWS_CM_10049]). The interface follows the service-oriented client/server pattern of the ara::com architecture (AUTOSAR_AP_SWS_CommunicationManagement p. 459). Typically, the SecOC subsystem of communication management acts as the service provider, implementing the service skeleton and verifying incoming secured PDU transmissions ([SWS_CM_10049]). Controlling applications—such as for vehicle diagnostics, test automation, or fault simulation—act as service consumers, requesting temporary or counter-limited manipulations of verification results via a service proxy object ([SWS_CM_10049]).

Methods, events, and fields

In version 1.0, the service interface declares exactly one method named VerifyStatusOverride ([SWS_CM_10049]). Events or fields do not exist in this interface (AUTOSAR_AP_SWS_CommunicationManagement p. 459). The method is explicitly not configured as fire-and-forget (Fire & Forget: false), which is why calls are acknowledged synchronously or asynchronously via a future object ([SWS_CM_10049]).

The method VerifyStatusOverride defines three mandatory input parameters ([SWS_CM_10049]):

• freshnessID (type uint16_t): Denotes the unique freshness identifier for which the override operation shall take effect ([SWS_CM_10049]).
• overrideStatus (type OverrideStatus): Determines via an enumeration value whether authentication verification is performed, whether the message is dropped or forwarded, and how long the override remains active ([SWS_CM_10049]).
• numberOfMessagesToOverride (type uint8_t): Specifies how many consecutive verification operations are to be overridden if a counter-based limit is used ([SWS_CM_10049]).

Lifecycle and Sequence of the Override

By invoking VerifyStatusOverride, a consuming application can deterministically manipulate the default behavior of SecOC ([SWS_CM_10049]). This allows messages to either be passed through or dropped regardless of the actual verification result or completely without checking ([SWS_CM_10049]). In addition, a specific VerificationStatusResult can be forced, allowing additional error handling mechanisms in receiving applications to be checked in a controlled manner ([SWS_CM_10049]).

The parameter numberOfMessagesToOverride has conditional semantics: It is evaluated exclusively when overrideStatus is set to one of the limit states kSecOcOverrideDropUntilLimit, kSecOcOverrideSkipUntilLimit, or kSecOcOverridePassUntilLimit ([SWS_CM_10049]). In these cases, the SecOC module presumably maintains an internal counter that is decremented with each incoming message with a matching freshnessID until the upper limit is reached and the service returns to normal operation (interpretation based on [SWS_CM_10049]). For other states, the override is likely to remain persistently active until it is modified by a new call (interpretation). Question Q-e916cb8cb1ee2992 (open)

Sequence diagram: Configuration sequence of verification override via VerifyStatusOverride. Sources: [SWS_CM_10049], AUTOSAR_AP_SWS_CommunicationManagement p. 459.

Error Handling and Feedback

Because VerifyStatusOverride is not a fire-and-forget call, the calling application receives confirmation of successful application of the configuration via the resulting ara::core::Future ([SWS_CM_10049]). Although the specification in DRAFT status does not list any specific application error codes (AUTOSAR_AP_SWS_CommunicationManagement p. 459), the service implementation is likely to acknowledge incorrect parameter values or unknown freshness IDs with an error (interpretation). Question Q-e810b3bffe576706 (open) Consuming applications must therefore always resolve and validate the future before injecting test-specific messages ([SWS_CM_10049]).