class ara::diag::CommunicationControl

In AUTOSAR Adaptive, the class ara::diag::CommunicationControl serves as an interface for processing the UDS service 0x28 (CommunicationControl) for switching communication channels [SWS_DM_00808]. After model-based instantiation via an InstanceSpecifier, Offer() enables the forwarding of requests by the Diagnostic Manager, which are subsequently processed asynchronously via CommCtrlRequest [SWS_DM_00806], [SWS_DM_00809]. As a strict non-copyable and non-movable type, the class excludes copy as well as move operations and requires deregistration via StopOffer() before termination [SWS_DM_00810].

more ›

Context

The class ara::diag::CommunicationControl defines the standardized interface for handling the UDS diagnostic service 0x28 (CommunicationControl) in the AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics, p. 70. As an abstract base class, it arbitrates between the Diagnostic Manager (DM) and the application-specific diagnostic functionality used to control the transmission or reception of specific communication messages in the in-vehicle network. The application software derives from this class and implements the pure virtual method CommCtrlRequest to receive and execute incoming control instructions [SWS_DM_00808]. Binding to the AUTOSAR system model is achieved via an ara::core::InstanceSpecifier referencing an PortPrototype of an DiagnosticComControlInterface [SWS_DM_00806].

Lifecycle

An instance is created explicitly via the constructor by specifying the ara::core::InstanceSpecifier as well as the concurrency model ConcurrencyType (kConcurrent or kNotConcurrent) [SWS_DM_00806]. The class possesses strict unique semantics and is neither copyable nor movable: both the copy constructor [SWS_DM_01677] and the move constructor [SWS_DM_01678], as well as the copy assignment operator [SWS_DM_01675] and the move assignment operator [SWS_DM_01676], are deleted (=delete).

After creation, the instance initially remains inactive. Only upon calling Offer() is the Diagnostic Manager authorized to forward incoming diagnostic requests to the handler [SWS_DM_00809]. Conversely, StopOffer() revokes this authorization and disables forwarding [SWS_DM_00810]. Destruction takes place via the virtual destructor [SWS_DM_00807]. Interpretation: Calling StopOffer() prior to the object's destruction is likely required so that the Diagnostic Manager does not maintain orphan forwardings. Question Q-f67e35c9fea508d8 (open)

Regarding concurrency, the constructor is thread-safe [SWS_DM_00806], whereas the destructor [SWS_DM_00807], Offer() [SWS_DM_00809], and StopOffer() [SWS_DM_00810] are not thread-safe. The execution of CommCtrlRequest is conditionally thread-safe (conditional): whether the implementation must be thread-safe is determined by the ConcurrencyType specified in the constructor [SWS_DM_00808].

Usage Path

The regular flow comprises the instantiation of the derived class, service registration, asynchronous processing of diagnostic requests, and final deregistration:

1. Initialization: The application instantiates the handler by specifying the InstanceSpecifier and the requested ConcurrencyType [SWS_DM_00806].
2. Service offer: The service is enabled at the Diagnostic Manager via Offer() [SWS_DM_00809].
3. Request processing: When a UDS request for service 0x28 arrives with any subfunction, the Diagnostic Manager calls CommCtrlRequest [SWS_DM_00808]. The parameters comprise:
   • controlType (ComCtrlRequestParamsType): All UDS request parameters including optional elements.
   • metaInfo (const MetaInfo&): Meta-information regarding the diagnostic request.
   • cancellationHandler (CancellationHandler): Used for status polling via IsCanceled() as well as for registering a cancellation callback function via SetNotifier().
4. Feedback: Processing completes asynchronously and reports the result back via ara::core::Future<void> [SWS_DM_00808].
5. Deregistration: Prior to shutdown or termination, the application stops forwarding using StopOffer() [SWS_DM_00810].

Sequence diagram: Typical sequence from initialization through UDS 0x28 request processing to deregistration. Sources: [SWS_DM_00806], [SWS_DM_00808], [SWS_DM_00809], [SWS_DM_00810].

Error Scenarios

Already during construction, inconsistencies in the AUTOSAR model can lead to runtime violations [SWS_DM_00806]:

• InstanceSpecifierMappingIntegrityViolation: The InstanceSpecifier cannot be resolved in the context of the executable or does not reference an PortPrototype.
• PortInterfaceMappingViolation: The PortPrototype typed by DiagnosticComControlInterface is not referenced by an DiagnosticServiceGenericMapping.
• ProcessMappingViolation: A matching instance reference exists, but there is no modeled process matching the current process.
• InstanceSpecifierAlreadyInUseViolation: The identifier is already used by another instance in the same process.

During normal operation, Offer() reports the error DiagOfferErrc::kAlreadyOffered via the return value ara::core::Result<void> if the service was already previously offered and is still active [SWS_DM_00809]. If a diagnostic request cannot be satisfied functionally in CommCtrlRequest, the method returns a Negative Response Code (NRC) in accordance with ISO 14229-1 via DiagUdsNrcErrc using the ara::core::Future<void> [SWS_DM_00808].