struct ara::diag::DataIdentifierConcurrencyType

The structure ara::diag::DataIdentifierConcurrencyType specifies the permissible concurrency behavior for diagnostic ports linked to data identifiers (Data Identifier) [SWS_DM_00936]. Via the member variables read, write, and readWrite, the application defines the extent to which Diagnostic Management (DM) may execute read and write calls in parallel. As an essential boundary condition, all fields are defensively pre-initialized to ConcurrencyType::kNotConcurrent by default, meaning concurrent execution is only permitted by explicitly setting them to kConcurrent [SWS_DM_00939].

more ›

Context

The C++ structure ara::diag::DataIdentifierConcurrencyType is used in the AUTOSAR Adaptive Platform to specify the concurrency behavior at ports linked to diagnostic data identifiers (Data Identifier, DID) [SWS_DM_00936]. It acts as a standardized configuration data type via which application software declares its capabilities for parallel processing to the diagnostic runtime system (AUTOSAR_AP_SWS_Diagnostics §8.8.2 “Struct: DataIdentifierConcurrencyType”). The structure is part of the interface definitions for the module diag (AUTOSAR_AP_SWS_Diagnostics p. 79).

The primary interaction partner is Diagnostic Management (DM). Incoming diagnostic requests are received by the DM and forwarded to the corresponding methods of the DataIdentifier port. Based on the values stored in DataIdentifierConcurrencyType, the DM decides whether read and write operations may be called concurrently or must be serialized sequentially [SWS_DM_00939].

Lifecycle

The structure is included via the header file ara/diag/concurrency.h and instantiated as a pure C++ data object (struct) [SWS_DM_00936]. Upon creation, all contained member variables are defensively initialized with the default value ConcurrencyType::kNotConcurrent [SWS_DM_00937]. This ensures that no parallel calls by the DM take place without explicit release by the application.

The lifecycle of the structure configuration is typically bound to the initialization of the associated DataIdentifier port. The application creates the object, sets the desired degrees of concurrency, and hands the configuration over to the port. During subsequent active diagnostic operation, the settings remain unchanged, allowing Diagnostic Management to schedule method calls deterministically (AUTOSAR_AP_SWS_Diagnostics §8.8.2.1 “Public Member Variables”).

The structure divides concurrency into three orthogonal configuration fields:

• read: Defines the concurrency type for read-only accesses (reads) [SWS_DM_00937].
• write: Defines the concurrency type for write accesses (writes) [SWS_DM_00938].
• readWrite: Defines the behavior during the joint, parallel invocation of read and write methods [SWS_DM_00939].

Usage Path

A regular usage path begins with the provision of a diagnostic service by an adaptive application. If the internal implementation of the port is thread-safe, the application can enable parallel execution of read and write accesses. For this purpose, an instance of DataIdentifierConcurrencyType is created and the field readWrite is set to ConcurrencyType::kConcurrent [SWS_DM_00939]. Likewise, read and write can be configured as needed [SWS_DM_00937], [SWS_DM_00938].

As soon as the DataIdentifier port is registered with the DM, the DM receives external diagnostic commands and forwards them (AUTOSAR_AP_SWS_Diagnostics p. 1115). When kConcurrent is set, the DM is allowed to execute incoming read and write calls simultaneously, optimizing throughput and latency [SWS_DM_00939]. If the configuration remains at the default value kNotConcurrent, the DM serializes the calls.

Sequence diagram: Typical flow of configuration and concurrent call dispatching by Diagnostic Management (DM). Sources: [SWS_DM_00936], [SWS_DM_00939].