namespace apext::com::secoc

The namespace defines the vendor-specific interface for managing freshness values within the scope of Secure Onboard Communication (SecOC) for AUTOSAR Adaptive Platform Communication Management (SWS Communication Management §C.1 “Header: apext/com/secoc/fvm.h”). The lifetime and initialization of the Freshness Value Manager are entirely controlled by Communication Management, which queries freshness values via the interface during configured transmission operations ([SWS_CM_11272]). If freshness values are temporarily unavailable, controlled retries occur up to a defined threshold before faulty messages are discarded. In addition, the namespace provides a dedicated error domain and standardized error codes for diagnostic and exception handling.

more ›

Context

The namespace apext::com::secoc defines normative Platform Extension Interfaces within the Communication Management (ara::com) functional cluster of the AUTOSAR Adaptive Platform (SWS Communication Management §C.1 “Header: apext/com/secoc/fvm.h”). The objective of these extension interfaces is to enable OEMs and stack vendors to provide a customized Freshness Value Manager (FVM) that generates, manages, and verifies the freshness values required to prevent replay attacks for Secure Onboard Communication (SecOC).

The namespace essentially interacts with three roles: Communication Management (ara::com), the standardized interface definition (FVM) including data carriers such as FVContainer ([SWS_CM_11286], [SWS_CM_11344]), and the concrete FVM implementation of the vehicle manufacturer or stack supplier. Interpretation: It is assumed that the vendor-specific FVM library is linked as a static or dynamic library as part of system integration, since the specification defines the functional interface but leaves the form of integration open in a stack-specific manner. Question Q-256aef3d6698cc3f (open)

Context diagram: Integration of the namespace apext::com::secoc between Communication Management and vendor-specific FVM implementation. Sources: [SWS_CM_11272], SWS Communication Management §C.1 “Header: apext/com/secoc/fvm.h”.

Lifecycle

The lifecycle management of an FVM implementation is controlled entirely by Communication Management ara::com ([SWS_CM_11272]). Applications and service instances do not create or manage the FVM component directly.

Startup takes place deterministically during the initialization of the communication stack by calling the library API apext::com::secoc::FVM::Initialize ([SWS_CM_11273]). If initialization cannot be properly completed on the vendor side, the FVM layer signals this error condition via the defined error code kFVInitializeFailed ([SWS_CM_11342]). After a successful initialization call, the Freshness Value Manager remains in the active operating state and answers synchronous requests for transmit and receive freshness values.

Usage Path

The regular usage path is divided into transmission protection and reception verification of messages:

• Transmit messages: If a message is configured for SecOC transmission, it is treated as an authentic message ([SWS_CM_11274]). Protection takes place in a fixed sequence after completion of all E2E protection calculations ([SWS_CM_11274]). If the service interface configuration possesses an attribute freshnessValueId, Communication Management calls apext::com::secoc::FVM::GetTxFreshness ([SWS_CM_11274], [SWS_CM_11275]). The freshness value is provided in a FVContainer structure, which holds the bit length in the attribute length and the value itself ([SWS_CM_11286], [SWS_CM_11344]).
• Transmit retry mechanism: For each secured message, the system maintains a Authentication Build Counter ([SWS_CM_11275]). After successful generation, the counter is reset to 0. If GetTxFreshness returns the recoverable error kFVNotAvailable or authenticator calculation fails, the counter is incremented and construction is retried ([SWS_CM_11275]). If the counter reaches the threshold SecOCAuthenticationBuildAttempts, the message is discarded ([SWS_CM_11275]).
• Receive messages: For incoming SecOC messages with active verification (attribute securedRxVerification true or unset), the authenticator is extracted and the message is verified prior to E2E checks by recalculating the MAC ([SWS_CM_11276], SWS Communication Management §8.1 “SecOC secure channel reception”). If securedRxVerification is set to false, however, verification is bypassed and the message is processed unverified ([SWS_CM_11372]).

Sequence diagram: Call and retry flow when protecting a transmit message using FVM. Sources: [SWS_CM_11274], [SWS_CM_11275].

Error Scenarios

Error situations within the FVM interface are handled via the type-safe error domain ComSecOcFvmErrorDomain, whose instance can be retrieved via GetComSecOcFvmErrorDomain ([SWS_CM_12521]). The error codes are defined in the enumeration type ComSecOcFvmErrc ([SWS_CM_11342]):

• kFVNotAvailable (code 1): The required freshness value is temporarily unavailable. This signals a recoverable error to Communication Management, which triggers retries according to the transmission protocol ([SWS_CM_11275], [SWS_CM_11342]).
• kFVInitializeFailed (code 2): Initialization of the Freshness Value Manager failed ([SWS_CM_11342]).

Via the helper function MakeErrorCode ([SWS_CM_12522]), error codes can be encapsulated into regular ara::core::ErrorCode objects together with vendor-specific supplementary data (SupportDataType). For failed synchronous calls in exception-based environments, the exception class ComSecOcFvmException is available.