struct ara::diag::CommunicationControl::ComCtrlRequestParamsType

The data structure bundles all input parameters of a UDS service request 0x28 for adaptive communication control according to [SWS_DM_00805]. Upon arrival of such a diagnostic message, the platform deserializes the control and communication types as well as the node identification and passes the populated structure to the corresponding service handler. The application software evaluates the contained values to specifically influence the transmission and reception behavior of defined network segments (AUTOSAR_AP_SWS_Diagnostics §8.7.2 “Struct: ComCtrlRequestParamsType”). As a stateless data container, the structure possesses no concurrency synchronization of its own, which is why accesses should remain within the execution context of the handler.

more ›

Context

The structure ara::diag::CommunicationControl::ComCtrlRequestParamsType is a central data transfer type within the functional diagnostic interface of AUTOSAR Adaptive [SWS_DM_00805]. It is declared in the header file ara/diag/communication_control.h and serves as a standardized parameter container encapsulating all input parameters of a diagnostic request of the UDS service 0x28 (CommunicationControl) (AUTOSAR_AP_SWS_Diagnostics §8.7.2 “Struct: ComCtrlRequestParamsType”).

In the overall system, the structure acts as an intermediary between AUTOSAR Diagnostic Management and the adaptive application software responsible for vehicle-specific communication control. Incoming diagnostic commands from external testers are deserialized at the platform level and passed to the application via this structure. The structure comprises three public member variables (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 “Public Member Variables”):

• controlType ([SWS_DM_01562], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.2 “controlType”): Defined as std::uint8_t, this field conveys the sub-function extracted from the UDS request to specify the control operation to be executed.
• communicationType ([SWS_DM_01563], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.1 “communicationType”): Likewise of type std::uint8_t, this field represents the communication type specified in the UDS request (such as normal or network management communication).
• nodeIdentificationNumber ([SWS_DM_01564], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.3 “nodeIdentificationNumber”): Defined as std::uint16_t, this variable identifies the specific target node or subnet to which the control instruction is directed.

Lifecycle

As an elementary C++ structure (struct) [SWS_DM_00805], ComCtrlRequestParamsType exhibits the characteristics of a simple value type (Plain Old Data / POD). It has no internal state machine, no virtual function pointers, and no dynamically allocated memory areas (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 “Public Member Variables”).

An instance is typically created transiently by the Diagnostic Management framework: As soon as a UDS 0x28 message has been received and formally validated, the stack instantiates the structure and initializes the member variables with the decoded payload (Interpretation: Object creation is entirely the responsibility of the middleware as part of request acceptance). Question Q-1abe8049ce5759f2 (open) Ownership is strictly limited to the context of the method call. The platform usually passes the instance by value or const reference to the service handler of the application; the receiving application does not take permanent ownership of the instance.

Accordingly, no lifecycle phases or complex state transitions exist. The destruction of the instance occurs automatically upon leaving the scope of the respective callback call. In terms of concurrency, ComCtrlRequestParamsType does not implement its own synchronization mechanisms. Since the members are usually evaluated in a read-only manner by the application software after initialization by the platform, access is expected to be thread-safe provided that the instance is passed thread-locally to the processing context (Interpretation: No external locks are required for evaluation). Question Q-d654753d06273bca (open)

Usage Path

The typical usage path within diagnostic processing takes place in a fixed sequence of steps from the network message to the application response (AUTOSAR_AP_SWS_Diagnostics §8.7.2 “Struct: ComCtrlRequestParamsType”):

1. Reception of the diagnostic message: An external diagnostic tester sends a UDS 0x28 request to the ECU. The Adaptive Diagnostic Management receives the data packet at transport layer.
2. Deserialization and instantiation: The diagnostic stack parses the payload, creates an instance of ComCtrlRequestParamsType [SWS_DM_00805], and assigns the transmitted values to the fields controlType [SWS_DM_01562], communicationType [SWS_DM_01563], and nodeIdentificationNumber [SWS_DM_01564].
3. Handoff to the service handler: The middleware forwards the instance to the implemented callback method of the CommunicationControl interface in the adaptive application.
4. Parameter evaluation and execution: The adaptive application reads out the structure. Based on the nodeIdentificationNumber [SWS_DM_01564], it is determined whether the node itself or a subnet is addressed. Subsequently, the corresponding transmission and reception modes are activated or deactivated via controlType [SWS_DM_01562] and communicationType [SWS_DM_01563].
5. Acknowledgment: After successful execution, the application confirms the process to Diagnostic Management, which transmits the standard-compliant positive UDS response to the diagnostic tester.

Sequence diagram: Typical flow of request processing from the UDS 0x28 message to parameter evaluation in the application. Sources: [SWS_DM_00805], AUTOSAR_AP_SWS_Diagnostics §8.7.2 “Struct: ComCtrlRequestParamsType”