class ara::diag::Condition

The class ara::diag::Condition provides the interface DiagnosticConditionInterface with which adaptive applications report environmental and enabling conditions to Diagnostic Management ([SWS_DM_00712]). The Diagnostic Server evaluates these states to selectively control the execution of standardized diagnostic functions or clearing procedures in the vehicle (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”). Instances are tied to a port prototype and are neither copyable nor movable. In concurrent use, the query and set operations require external synchronization because they are not thread-safe.

more ›

Context

The class ara::diag::Condition represents the programming interface for diagnostic conditions (DiagnosticConditionInterface) in the AUTOSAR Adaptive Platform ([SWS_DM_00712]). In vehicle diagnostic systems, certain diagnostic functions or UDS services may only be executed if the vehicle is in a defined environmental state—such as when the vehicle is stationary with a speed of zero (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”). In accordance with [SWS_DM_00111], the Diagnostic Server performs corresponding environmental checks when ISO 14229-1 prescribes service-specific condition checks, and responds with a configured Negative Response Code (NRC) if they are not satisfied.

Within the application architecture, ara::diag::Condition acts as a link between the adaptive application and Diagnostic Management (DM). An application instantiates the condition object via a port linked in the model either via an DiagnosticEnableConditionPortMapping or an DiagnosticClearConditionPortMapping ([SWS_DM_00712]). Interpretation: This port mapping defines whether the reported state serves as an enabling condition for regular diagnostic routines or as a criterion for clearing diagnostic data. Question (open) The object thus encapsulates state transmission to the Diagnostic Server, which evaluates the conditions for incoming diagnostic requests ([SWS_DM_00111]).

Context diagram: Integration of ara::diag::Condition between application software and Diagnostic Management. Sources: [SWS_DM_00712], [SWS_DM_00111], AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”

Lifecycle

Creation of an ara::diag::Condition object is performed explicitly by passing an ara::core::InstanceSpecifier to the constructor ([SWS_DM_00712]). This identifier references the modeled port prototype of the application. The constructor is declared as noexcept and guarantees exception safety as well as thread safety ([SWS_DM_00712]).

Regarding ownership semantics, the class is designed as a strict single instance: both the copy constructor ([SWS_DM_01625]) and the copy assignment operator ([SWS_DM_01623]) are deleted (=delete). Likewise, the move constructor ([SWS_DM_01626]) and the move assignment operator ([SWS_DM_01624]) are deleted. A condition object can neither be copied nor moved, ensuring a fixed 1:1 association with the respective port.

During normal operation, the methods SetCondition ([SWS_DM_00715]) and GetCondition ([SWS_DM_00714]) are specified as not thread-safe. In case of parallel access from multiple threads, the calling application must ensure external synchronization. The lifecycle concludes with the destructor ~Condition() ([SWS_DM_00713]), which is noexcept and exception-safe, but likewise not thread-safe.

Usage Path

The typical usage path comprises initialization, recurrent updating of the state, and querying the condition:

1. Initialization: The application instantiates ara::diag::Condition by specifying the matching ara::core::InstanceSpecifier ([SWS_DM_00712]) for connection to the model configuration.
2. Set state: When the decisive vehicle or system state changes, the application updates the condition via SetCondition(condition) ([SWS_DM_00715]). The call confirms acceptance with an ara::core::Result<void>.
3. Query state: To verify the current state, the application calls GetCondition() ([SWS_DM_00714]). The result is provided asynchronously via an ara::core::Future<ConditionType>.
4. Server processing: Interpretation: The Diagnostic Server internally accesses the stored state to verify pending diagnostic requests ([SWS_DM_00111]). Question Q-bbf48f735ef80e33 (open)
5. Termination: Upon termination of the component, the object is released via the destructor ([SWS_DM_00713]).

Sequence diagram: Typical call sequence for initializing, updating, and querying a diagnostic condition. Sources: [SWS_DM_00712], [SWS_DM_00715], [SWS_DM_00714], [SWS_DM_00713]

Error Scenarios

Error states can occur during object instantiation as well as during runtime:

• Constructor violations: During creation ([SWS_DM_00712]), the framework validates the configuration against the software model. Possible violations include:
  • InstanceSpecifierMappingIntegrityViolation: The identifier cannot be resolved in the model or does not reference a PortPrototype ([SWS_DM_00712]).
  • PortInterfaceMappingViolation: Although the PortPrototype is typed by DiagnosticConditionInterface, it is referenced neither by an DiagnosticEnableConditionPortMapping nor by an DiagnosticClearConditionPortMapping ([SWS_DM_00712]).
  • ProcessMappingViolation: No matching modeled process exists at runtime for the instance reference ([SWS_DM_00712]).
  • InstanceSpecifierAlreadyInUseViolation: The identifier is already used by another instance within the same process ([SWS_DM_00712]).
• Failure of diagnostic core services: GetCondition() ([SWS_DM_00714]) can fail with the error DiagErrc::kServiceNotAvailable via the returned ara::core::Future if basic functionalities of Diagnostic Management are temporarily unreachable.
• Error-free state storage: No standardized error codes are defined for SetCondition() ([SWS_DM_00715]); the function reports success directly via an empty ara::core::Result<void>.