namespace <RoutineInterface-Namespace>

This namespace provides interfaces for encapsulating and executing application-specific diagnostic routines within the diag module of the Adaptive Platform. The primary task is presumably to offer an abstraction layer for routine operations such as starting, stopping, and result queries to the diagnostic management system. Question (open) Controlling routine execution is likely typically coupled to the lifecycle of the parent diagnostic stack. As an essential constraint, implementations must ensure the required thread safety and deterministic behavior for asynchronous calls.

more ›

Context

The namespace namespace <RoutineInterface-Namespace> is part of the functional cluster diag (Diagnostic Management) of the AUTOSAR Adaptive Platform in release R25-11. Within this namespace, the interface class <RoutineInterface> is defined as DiagnosticRoutineInterface. The primary role of this namespace consists in providing a standardized framework for encapsulating diagnostic routines that are executed by application software components in the vehicle.

The class <RoutineInterface> is likely to serve as an abstraction layer between the platform's diagnostic management system and the vehicle-specific routine workflows. Question Q-03b9b94f9c2849b0 (open) The parent diagnostic management processes external diagnostic requests (such as UDS RoutineControl according to ISO 14229-1) and forwards them to the registered application routine. Via the implementation of the interface, the application provides the actual control, test, and verification logic without exhibiting direct dependencies on the transport protocol layer or network topologies.

Lifecycle

The lifecycle of instances of the interface class <RoutineInterface> is likely to be tightly coupled to the provisioning state of the associated diagnostic services. Question Q-32a86efa16843445 (open) Instantiation typically occurs in the course of the initialization phase of the adaptive application before the interface is registered with the diagnostic manager and enabled for external requests. In this process, the application assumes responsibility for object creation and the provisioning of required execution contexts.

During the operating phase, the interface instance remains active and accepts incoming control commands. Because diagnostic calls by external testers can arrive concurrently with regular application tasks, implementations must guarantee the required thread safety. Upon termination of the application or deactivation of the service, an orderly deregistration is required to ensure that no running routines remain in an undefined state and allocated resources are deterministically released.

Usage Path

A typical usage path for a diagnostic routine is structured into a sequence of interaction steps between the diagnostic management system and the application logic. The sequence is likely to comprise the following phases: Question Q-da2cd4e1ceb5b3b8 (open)

1. Initialization and registration: The application instantiates class <RoutineInterface> and registers the interface object with the diagnostic management of module diag.
2. Start of the routine: Upon receipt of a corresponding diagnostic request, the system calls the start method of the interface. This triggers the application-specific logic, such as an actuator test, a calibration run, or a calculation cycle.
3. Status and result query: During execution or after completion of the operation, intermediate states or the final result can be queried via corresponding interface calls and passed to the management system.
4. Termination or premature abort: The routine is terminated either regularly after successful processing or aborted in a controlled manner upon an explicit stop request from the diagnostic infrastructure if needed.

Error Scenarios

During routine execution, various error conditions can arise that require consistent error handling. If unforeseen operating states occur during execution of a diagnostic routine—such as insufficient supply voltage, impermissible vehicle states, or resource bottlenecks—the interface must signal this. Erroneous input parameters or execution aborts must be reported back to the diagnostic management via defined error codes. This enables the platform to transmit standard-compliant negative response codes (NRCs) to the external diagnostic tester and maintain a safe vehicle state.