class ara::diag::DoIPGroupIdentification

Class ara::diag::DoIPGroupIdentification serves as an abstract interface for Adaptive applications to provide the current DoIP group identification status to Diagnostic Management [SWS_DM_00724]. After port-specific instantiation, the application activates the forwarding of requests via Offer() and stops it prior to object destruction using StopOffer() [SWS_DM_00725]. The handler instance is unique, neither copyable nor movable, and answers queries asynchronously via a ara::core::Future.

more ›

Context

Class ara::diag::DoIPGroupIdentification provides the functional interface of Diagnostic Management (AUTOSAR AP SWS Diagnostics p. 73) through which an adaptive application provides the current group identification status (GID status) for the DoIP protocol [SWS_DM_00724]. Within the platform architecture, the class acts as an intermediary between two primary interaction partners: the internal Diagnostic Management daemon (DM), which handles standardized vehicle identification and DoIP messages over the network, and the application-specific implementation, which concretizes pure virtual method GetGidStatus(). Providing and accepting requests is controlled via explicit service offerings [SWS_DM_00725].

Lifecycle

An instance of DoIPGroupIdentification represents a unique diagnostic port. For this reason, the class is designed as a uniquely managed object: Both copy constructor [SWS_DM_01641] and move constructor [SWS_DM_01642] as well as the corresponding assignment operators [SWS_DM_01639], [SWS_DM_01640] are explicitly deleted (=delete).

Creation is strictly performed via the parameterized constructor by specifying a ara::core::InstanceSpecifier as well as concurrency mode ConcurrencyType [SWS_DM_00722]. The lifecycle is divided into the following phases:

• Not Offered: After construction, the object exists in the address space of the process, but does not yet receive requests from the DM.
• Offered: By synchronously calling Offer() [SWS_DM_00725], the handler is activated with the DM so that incoming DoIP status requests are forwarded.
• Stopped: Calling StopOffer() [SWS_DM_00726] revokes the forwarding authorization from the DM and transitions the object back to the inactive state.

Destruction occurs via virtual destructor ~DoIPGroupIdentification() [SWS_DM_00723]. Regarding concurrency, the constructor is thread-safe, whereas Offer(), StopOffer(), and the destructor are not thread-safe [SWS_DM_00722], [SWS_DM_00723], [SWS_DM_00725], [SWS_DM_00726]. The thread safety of query function GetGidStatus() is conditionally defined by the ConcurrencyType selected in the constructor [SWS_DM_00724]. Interpretation: The destructor presumably terminates ongoing forwardings implicitly if StopOffer() was not called beforehand. Question Q-50d70fb679462321 (open)

Usage Path

Typical usage comprises initialization, activation, asynchronous processing, and deactivation:

1. A concrete diagnostic class inherits from ara::diag::DoIPGroupIdentification and implements method GetGidStatus() [SWS_DM_00724].
2. The application creates the object with the InstanceSpecifier of the configured PortPrototype and specifies whether GetGidStatus() may be invoked concurrently (kConcurrent) or not (kNotConcurrent) [SWS_DM_00722].
3. Using Offer(), the application arms the handler for Diagnostic Management [SWS_DM_00725].
4. As soon as DoIP requests arrive, the DM calls GetGidStatus(); the application returns the GID state asynchronously via ara::core::Future<GidStatus> [SWS_DM_00724].
5. Before stopping the service or shutting down the component, the application calls StopOffer() [SWS_DM_00726], followed by destruction of the object [SWS_DM_00723].

Sequence diagram: Typical sequence of instantiation, activation, status query, and deactivation. Sources: [SWS_DM_00722], [SWS_DM_00724], [SWS_DM_00725], [SWS_DM_00726].

Error Scenarios

When using DoIPGroupIdentification, error conditions are defined in the construction and offering phases:

• Model and mapping errors (constructor): If instantiation fails, standardized violations are reported [SWS_DM_00722]:
  • InstanceSpecifierMappingIntegrityViolation: The identifier cannot be resolved or does not reference a port prototype.
  • PortInterfaceMappingViolation: The referenced port is not typed as DiagnosticDoIPGroupIdentificationInterface.
  • ProcessMappingViolation: No matching process is mapped to the execution context in the model.
  • InstanceSpecifierAlreadyInUseViolation: The specified port identifier is already in use by another instance in the running process.
• Service offering errors (Offer()): The method returns a ara::core::Result<void>. If the service was already offered successfully for this handler, a repeated call fails with error code DiagOfferErrc::kAlreadyOffered [SWS_DM_00725].
• Errors during status query: Interface GetGidStatus() specifies no standardized error codes [SWS_DM_00724]; application-internal errors must be mapped via the result object of the returned future.