namespace <DataElement-Namespace>

The namespace <DataElement-Namespace> bundles interfaces generated in the AUTOSAR Adaptive module diag for release R25-11 for the structured connection of application-specific diagnostic data elements to the central diagnostic system. Via the interface class <DataElementInterface>, the adaptive application implements concrete read and write operations that are executed by the diagnostic stack upon incoming diagnostic requests. Regarding the lifecycle, creating and registering the interface instance is the responsibility of the application, where Interpretation: the instance must be kept valid over the entire operating time and thread-safe for concurrent calls.

more ›

Context

Within the scope of the AUTOSAR Adaptive Platform for release R25-11, the functional cluster diag (Diagnostic Management) provides standardized mechanisms to provide vehicle diagnostic services according to UDS and link them with in-vehicle functions. The namespace <DataElement-Namespace> forms the logical framework for interfaces for acquiring and modifying diagnostic data elements. The identifier <DataElement-Namespace> is likely to function as a generic placeholder for a model-specific C++ namespace instantiated during code generation from formal ARXML model descriptions for a specific diagnostic data element. Question Q-2a710983ba4634ab (open)

The central element within this namespace is the class <DataElementInterface>, which is typed as DiagnosticDataElementInterface. This interface forms the formal contract between the adaptive diagnostic stack and the application-specific software component. The declared interface class <DataElementInterface> serves for application connection, presumably to delegate read and write operations on diagnostic data elements such as data identifiers (DIDs) to the adaptive application in a type-safe manner. Question Q-5fbb9db6b949d851 (open) In this way, a clear decoupling between the generic protocol handling of the diagnostic service and the internal data provisioning of the ECU is ensured.

Lifecycle

The lifecycle of the components defined in <DataElement-Namespace> is coupled to the execution phases of the adaptive application and the diagnostic manager. Instantiation of a concrete implementation of <DataElementInterface> regularly takes place during the initialization and startup phase of the respective application process. Regarding ownership, creating and destroying the concrete implementation of <DataElementInterface> is the responsibility of the utilizing application, where Interpretation: the instance must be kept valid throughout the entire registration and operating phase in the diagnostic system before it may be safely released during deinitialization.

During the operational phase, the registered interface instance remains in the ready-to-receive state for incoming diagnostic requests. Because external diagnostic requests arrive asynchronously via the diagnostic stack and can be processed by worker threads of the runtime system, the implementation of the interface methods must be designed to be thread-safe and reentrant. Prior to shutting down the application process, the binding to the diagnostic manager must be released to prevent invalid pointer accesses to destroyed interface objects.

Usage Path

The typical usage of the interfaces from <DataElement-Namespace> is divided into implementation, registration, runtime servicing, and cleanup. The application software first derives a concrete class from <DataElementInterface> and overrides the required callback methods for accessing the diagnostic data. At startup, the application instantiates this class and registers it as a data provider with the runtime environment of module diag.

If the diagnostic cluster then receives a UDS service request (for example, to query or program a DID), it delegates the data access directly to the registered instance of <DataElementInterface>. The application reads or updates the requested data and returns the result to the diagnostic system, which generates the diagnostic response from it. Upon orderly termination of the application, the instance is deregistered and memory is properly released.