class ara::diag::SovdServiceValidation

The class ara::diag::SovdServiceValidation serves for application-specific verification of access rights and preconditions for incoming SOVD service requests ([SWS_DM_01822]). Following port instantiation and explicit activation via Offer(), Diagnostic Management calls the asynchronous validation method Validate() for each requested resource ([SWS_DM_01827]). If the validation returns an error value for even a single sub-resource, the system immediately aborts the entire processing and rejects the client request. While instantiation is thread-safe, methods such as Offer() and StopOffer() must be synchronized by the caller.

more ›

Context

In the Adaptive Platform, the class ara::diag::SovdServiceValidation serves to provide manufacturer- and supplier-specific checks for Service-Oriented Vehicle Diagnostics (SOVD) within a diagnostic application ([SWS_DM_01822]). While standardized preconditions and environmental conditions within the scope of the SOVD protocol are evaluated by Diagnostic Management (DM) prior to method execution ([SWS_DM_01468]), this interface delegates custom validation logics directly to the adaptive application.

Three central parties are involved in service validation:

• SOVD client: Initiates diagnostic requests to the vehicle system via HTTP methods.
• Diagnostic Management (DM): Receives SOVD requests, checks higher-level conditions, and delegates validation to the configured port mappings ([SWS_DM_01467], SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”).
• Validation handler: Implements the application-specific specialization of SovdServiceValidation and decides on the admissibility of the requested operation ([SWS_DM_01822], [SWS_DM_01827]).

Context diagram: Components and interface relationships in SOVD service validation. Sources: [SWS_DM_01822], [SWS_DM_01823], SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”

Lifecycle

Instantiation of a validation handler takes place via the constructor of SovdServiceValidation, which is bound via an ara::core::InstanceSpecifier to an PortPrototype modeled in the manifest ([SWS_DM_01823]). The port must be typed by an DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). Via the parameter ConcurrencyType, the application bindingly defines whether its implementation is designed for concurrent calls (kConcurrent) or must be served non-concurrently (kNotConcurrent) ([SWS_DM_01823]).

After successful construction, the instance is in the initialized state. Forwarding of requests by the DM must be explicitly activated by calling Offer() ([SWS_DM_01825]). If forwarding is to be interrupted or terminated, the application deactivates it via StopOffer() ([SWS_DM_01826]). The virtual destructor ~SovdServiceValidation() cleanly terminates the handler's lifecycle ([SWS_DM_01824]). While the constructor itself is specified as thread-safe, Offer(), StopOffer(), and the destructor are not thread-safe and must not be called concurrently ([SWS_DM_01823], [SWS_DM_01824], [SWS_DM_01825], [SWS_DM_01826]).

Usage Path

The typical validation sequence is divided into the following phases:

1. Initialization and registration: The application instantiates the specialized class and enables the service for the DM using Offer() ([SWS_DM_01823], [SWS_DM_01825]). Interpretation: This typically takes place when starting the application's diagnostic functionality. Question (open)
2. Request processing: When an SOVD message arrives at the Diagnostic Server, it calls the method Validate in the defined order for each port mapping configured in DiagnosticServiceValidationConfiguration (SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”).
3. Resource check: If the call affects a resource collection, the DM calls Validate multiple times: exactly once for the collection itself and subsequently once for each resource contained in the collection ([SWS_DM_01827]). The path of the currently checked resource is passed in ara::diag::MetaInfo in each case (SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”).
4. Asynchronous result: The method returns an ara::core::Future<void> ([SWS_DM_01827]). If the check is successful, the future is resolved without an error value and the DM continues processing the request (SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”).
5. Service deactivation: Before termination or upon configuration changes, the application calls StopOffer() ([SWS_DM_01826]).

Sequence diagram: Sequence of an SOVD request check via Validate with resource iteration and error handling. Sources: [SWS_DM_01827], SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”

Error Scenarios

Errors can occur in different phases of initialization and execution:

• Construction violations: If the InstanceSpecifier cannot be resolved in the model or does not point to an PortPrototype, an InstanceSpecifierMappingIntegrityViolation is reported ([SWS_DM_01823]). An PortInterfaceMappingViolation occurs if the port does not match the interface DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). In case of a missing process mapping, ProcessMappingViolation occurs, and if the same identifier is used multiple times, an InstanceSpecifierAlreadyInUseViolation follows ([SWS_DM_01823]).
• Registration errors upon Offer: If the service has already been actively offered, Offer() returns the error DiagOfferErrc::kAlreadyOffered ([SWS_DM_01825]). If the configuration deviates from the DEXT modeling, the error DiagOfferErrc::kConfigurationMismatch results ([SWS_DM_01825]).
• Functional validation errors: The method Validate reports inadmissibilities via error codes from DiagSovdErrc ([SWS_DM_01827]). These include DiagSovdErrc::kInsufficientAccessRights in case of insufficient client permissions, DiagSovdErrc::kPreconditionNotFulfilled in case of unsatisfied preconditions, DiagSovdErrc::kTemporarilyNotAvailable in case of temporary unavailability (e.g., missing online token validation), or DiagSovdErrc::kSovdServerMisconfigured in case of incorrect configuration ([SWS_DM_01827]).
• Immediate abortion on sub-resource errors: If validation fails for even a single contained resource of a resource collection, the DM immediately aborts processing of the overall request and returns an error message directly to the client (SWS Diagnostics §7.3.3.2.3 “SOVD – Validation of Environmental Conditions”).