Communication Manager (ComM)

The synchronous function ComM_Init (service ID 0x01) serves for the fundamental initialization of the AUTOSAR Communication Manager and restarts its internal state machines [SWS_ComM_00146]. As input parameter, it accepts ConfigPtr, which is passed as a pointer to the post-build configuration structure of type const ComM_ConfigType* [SWS_ComM_00146]. The function provides no return value (return type void) and is declared via the header file ComM.h [SWS_ComM_00146].

Regarding concurrency, ComM_Init is defined as non-reentrant (Non Reentrant) [SWS_ComM_00146]. A specific caller is not specified in the specification data; the call presumably takes place centrally during the startup phase of the ECU within the scope of BSW initialization. Question Q-7121f73c12407087 (open)

In the overall system, ComM_Init has a central control and precondition function for the entire module: As long as the ComM module has not been initialized, all module and API services must not enter regular operation and must report back E_NOT_OK for services with standard return type [SWS_ComM_00612]. An exception to this lock applies exclusively to ComM_Init itself as well as to the query functions ComM_GetVersionInfo and ComM_GetStatus [SWS_ComM_00612].

use

According to [SWS_ComM_00147], the function ComM_DeInit serves to deinitialize the AUTOSAR Communication Manager (ComM). The service is designed synchronously, has the service ID 0x02, and is declared via the header file ComM.h. According to signature void ComM_DeInit(void), the function accepts no input, output, or transfer parameters and returns no value to the caller [SWS_ComM_00147].

Error handling

Since the function signature returns void, no direct feedback of error or status codes occurs via the interface call [SWS_ComM_00147]. Specific error responses, such as notification of the Development Error Tracer (DET) or the Diagnostic Event Manager (DEM), are not contained in the available specification data and are therefore not shown.

Concurrency and System Context

According to [SWS_ComM_00147], the interface is specified as non-reentrant (Non Reentrant). This implies the mandatory requirement for system integration to completely prevent parallel or preemptive calls from multiple tasks or contexts. As an interpretation of the system flow, the call is likely to occur typically during orderly ECU shutdown by a higher-level state management (such as the BSW Manager) as soon as the communication channels of the BSW have been shut down. Question Q-f3b68dc129993cb7 (open)

Usage and Call Context

The synchronous and reentrant function ComM_RequestComMode ([SWS_ComM_00110]) serves to request a communication mode for a defined user (User). It is available via ComM.h. As input parameters for ComMode, exclusively the following values are permitted as user requests:

• COMM_FULL_COMMUNICATION: Request for full communication capability ([SWS_ComM_00110]).
• COMM_NO_COMMUNICATION: Release or termination of the communication request ([SWS_ComM_00110]).

The modes COMM_SILENT_COMMUNICATION (serves for shutdown synchronization) and COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST (internal wakeup trigger for underlying layers, e.g. for OA TC10-capable Ethernet hardware) are internal states and must not be requested by users ([SWS_ComM_00110]). Interpretation: Passing these internal modes is presumably acknowledged with E_NOT_OK. Question Q-973ed1ce1845983e (open)

Return Values and Error Handling

The function signals the result via defined return values ([SWS_ComM_00110]):

• E_OK: The switch to the desired communication mode was successfully performed.
• E_NOT_OK: The mode transition failed.
• COMM_E_MODE_LIMITATION: The requested mode cannot be granted due to an active communication limitation (mode inhibition). Communication requests can also be released again by such limitations.

Interaction and State Machine

The presence or absence of active requests affects the channel state machine of the ComM. If the channel is in the sub-state COMM_FULL_COM_NETWORK_REQUESTED with configuration ComMNmVariant = SLAVE_ACTIVE and there is no active call to ComM_RequestComMode(<user>, COMM_FULL_COMMUNICATION), the ComM state machine transitions to the sub-state COMM_FULL_COM_READY_SLEEP ([SWS_ComM_01017]).

The synchronous function ComM_UpdatePncToChannelMapping with service ID 0x62 serves to set entries in the PNC-to-channel mapping of the ECU or the PNC gateway [SWS_ComM_91015]. The interface is available via header file ComM.h and is marked with draft status in release R20-11 [SWS_ComM_91015].

Parameters

Three input parameters are passed to the function call [SWS_ComM_91015]:

• MappingTable: Pointer to a two-dimensional boolean array (const boolean*) containing the current PNC-to-channel mapping of the PNC gateway, where the first dimension covers all relevant channels and the second dimension covers all relevant PNCs [SWS_ComM_91015].
• channelCnt: Number of physical channels passed in MappingTable [SWS_ComM_91015].
• PncCnt: Number of PNCs passed in MappingTable [SWS_ComM_91015].

Return Values and Error Handling

The function returns a status value of type Std_ReturnType [SWS_ComM_91015]:

• E_OK: The mapping entry was set successfully [SWS_ComM_91015].
• E_NOT_OK: Setting the mapping entry failed [SWS_ComM_91015].
• COMM_E_LEARNING_ACTIVE: The call cannot be executed because the PNC learning phase is active [SWS_ComM_91015].

Concurrency and Limitations

The interface is defined as non-reentrant [SWS_ComM_91015]. Calls must therefore not occur concurrently. Furthermore, an update is excluded as long as the communication system is in the active PNC learning phase [SWS_ComM_91015].

The synchronous, non-reentrant function ComM_ResetPncToChannelMapping serves to reset dynamic entries of the ECU's PNC-to-channel mapping to the configured default values [SWS_ComM_91017]. It takes no input parameters and returns a status value of type Std_ReturnType [SWS_ComM_91017].

Behavior and Return Values

The behavior of the function depends on the state of the PNC learning phase as well as the configuration of the channels:

• If ComMDynamicPncToChannelMappingEnabled is enabled for at least one channel and the PNC learning phase is not active, the function resets the mappings to the default values of the initial configuration (static entries) and returns E_OK [SWS_ComM_01043].
• If the system is in an active PNC learning phase and ComMDynamicPncToChannelMappingEnabled or ComMDynamicPncToChannelMappingSupport is set to TRUE for at least one channel, the reset is rejected and COMM_E_LEARNING_ACTIVE is returned [SWS_ComM_01042], [SWS_ComM_01045].
• If resetting the mappings to the default values fails, the function returns E_NOT_OK [SWS_ComM_91017].

Constraints and Call Conditions

Since ComM_ResetPncToChannelMapping is specified as non-reentrant (Non Reentrant), concurrent calls from parallel contexts must not occur [SWS_ComM_91017]. In addition, the interface is in draft status [SWS_ComM_91017].

Usage and Semantics

The asynchronous function ComM_PnLearningRequest triggers the optional dynamic PNC-to-channel mapping [SWS_ComM_91019]. It causes the Network Management (NM) to return to the NM Repeat Message State [SWS_ComM_91019]. In doing so, the Partial Network Learning Bit is transmitted so that receiving nodes respond, and the Repeat Message Request Bit is transmitted so that receiving nodes also transition into the NM Repeat Message State [SWS_ComM_91019]. The call is made without input parameters via the interface in ComM.h with service ID 0x64 [SWS_ComM_91019].

Return Values and Error Handling

The function returns a status value of type Std_ReturnType [SWS_ComM_91019]:

• E_OK: The PNC learning algorithm was started successfully [SWS_ComM_91019].
• E_NOT_OK: The PNC learning algorithm could not be started [SWS_ComM_91019].
• COMM_E_LEARNING_ACTIVE: The function call cannot be executed because the PNC learning phase is already active [SWS_ComM_91019].

Concurrency and Configuration

The function is specified as non-reentrant (Non Reentrant) and has the status draft [SWS_ComM_91019]. It is available exclusively when pre-configuration parameter ComMDynamicPncToChannelMappingSupport is set to TRUE [SWS_ComM_01044].

The synchronous and non-reentrant function ComM_UpdatePncMembership is used by Software Components (SWCs) to adapt the PNC membership transmitted during PNC learning for the optional dynamic PNC-to-channel mapping [SWS_ComM_91021]. It is available via header ComM.h only if configuration parameter ComMDynamicPncToChannelMappingSupport is set to TRUE [SWS_ComM_01047].

Parameter ComM_PncMembership passes a byte array with the length of the PNC vector containing the current PNC membership of the node [SWS_ComM_91021]. If the function is enabled on at least one channel and the PNC learning phase is inactive, parameter Control is evaluated [SWS_ComM_01049]:

• For Control = 0, the current PNC membership is calculated by means of a logical AND operation with ComM_PncMembership in order to specifically clear corresponding bits in the mask [SWS_ComM_01049].
• For Control = 1, a logical OR operation is applied to set bits in the mask [SWS_ComM_01049].

If the update was successful, the function returns E_OK [SWS_ComM_01049]. If, on the other hand, dynamic mapping is configured on at least one channel and the PNC learning phase is active, execution is rejected and the specific error value COMM_E_LEARNING_ACTIVE is reported [SWS_ComM_01048]. If another error occurs during the update process, E_NOT_OK is returned [SWS_ComM_91021].

Usage and Call Context

According to [SWS_ComM_00156], the function ComM_PreventWakeUp serves to change the inhibition status COMM_NO_WAKEUP for a specific communication channel. It is executed synchronously and is available via the header file ComM.h.

Two input parameters are passed upon calling:

• Channel: Identifies the relevant channel according to type NetworkHandleType ([SWS_ComM_00156]).
• Status: A boolean value used to enable (TRUE) or disable (FALSE) the wake-up inhibition ([SWS_ComM_00156]).

Return Values and Error Handling

As return value, the function provides status Std_ReturnType according to [SWS_ComM_00156]:

• E_OK: The wake-up status for the specified channel was successfully updated.
• E_NOT_OK: Changing the wake-up status failed, for example if the functionality is disabled via ECU group classification (ComMEcuGroupClassification).

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) ([SWS_ComM_00156]). Callers must therefore ensure that parallel calls for the same instance are avoided.

The synchronous function ComM_LimitChannelToNoComMode with service ID 0x0b serves in Communication Manager to set the inhibition status for a single communication channel [SWS_ComM_00163]. It prevents or permits the channel to transition from state COMM_NO_COMMUNICATION to a higher-level communication mode [SWS_ComM_00163].

Parameters and call context

The interface is declared via the header file ComM.h and has neither input/output nor pure output parameters [SWS_ComM_00163]. Two input parameters are passed upon calling [SWS_ComM_00163]:

• Channel: Addresses the respective channel via the identifier of type NetworkHandleType [SWS_ComM_00163].
• Status: Determines the desired inhibition state as boolean. Passing TRUE enables the limitation of the channel to COMM_NO_COMMUNICATION, whereas FALSE disables this limitation again [SWS_ComM_00163].

Return Values and Error Handling

The function returns a value of type Std_ReturnType to the caller [SWS_ComM_00163]:

• E_OK: The inhibition status for the addressed channel was successfully adapted [SWS_ComM_00163].
• E_NOT_OK: The status change could not be performed, which is the case, for example, if configuration ComMEcuGroupClassification (see ECUC_ComM_00563) disables the functionality [SWS_ComM_00163].

Concurrency and System Context

With regard to execution behavior, the function is implemented synchronously (Synchronous) and non-reentrant (Non Reentrant) [SWS_ComM_00163]. For the same purpose at overall system level, there is the related function ComM_LimitECUToNoComMode, which implements the same limitation not only channel-specifically, but uniformly for all channels of the ECU [SWS_ComM_00163].

use

The synchronous function ComM_LimitECUToNoComMode (service ID 0x0c) is defined in ComM.h and serves to change the inhibition status for the entire ECU [SWS_ComM_00124]. It prevents or permits the transition from COMM_NO_COMMUNICATION to a higher communication mode for all communication channels of the ECU [SWS_ComM_00124]. Control is performed via the formal parameter Status:

• TRUE: Enables the inhibition of the ECU to mode COMM_NO_COMMUNICATION [SWS_ComM_00124].
• FALSE: Disables the inhibition of the ECU to COMM_NO_COMMUNICATION again [SWS_ComM_00124].

Error Handling and Return Values

The function returns a status code of type Std_ReturnType to the caller [SWS_ComM_00124]:

• E_OK: The inhibition status for the ECU was successfully applied [SWS_ComM_00124].
• E_NOT_OK: The change of the inhibition status failed, for example if the configuration parameter ComMEcuGroupClassification (see ECUC_ComM_00563) disables the functionality [SWS_ComM_00124].

A caller must evaluate the return value to recognize whether the inhibition could be activated or was rejected by the module configuration [SWS_ComM_00124].

Concurrency and Interaction

The interface is declared as non-reentrant (Non Reentrant); parallel or interrupting calls are therefore impermissible and must be avoided on the caller side [SWS_ComM_00124]. While ComM_LimitChannelToNoComMode provides the same control functionality in isolation for an individual channel, ComM_LimitECUToNoComMode always affects all channels of the ECU [SWS_ComM_00124].

Usage and Call Context

The synchronous function ComM_ReadInhibitCounter (service ID 0x0d) serves to query the number of rejected user requests for full communication mode (COMM_FULL_COMMUNICATION) [SWS_ComM_00224]. The function declaration is provided via the header file ComM.h [SWS_ComM_00224].

The function has no input parameters. The only output parameter is the pointer CounterValue of base type uint16*, via which the counter value for the rejected requests is transmitted to the caller [SWS_ComM_00224]. If the counter value could be successfully determined and written, the function returns E_OK; upon failure, it returns E_NOT_OK [SWS_ComM_00224].

Error handling

Specific error codes or standardized development errors (DET) are not separately listed in the interface description. A failure with return value E_NOT_OK [SWS_ComM_00224] is presumably caused by an invalid pointer parameter (null pointer) or a call prior to the initialization of the ComM module (interpretation). Question Q-5779d898381d9894 (open)

Concurrency and Limitations

The interface is explicitly specified as non-reentrant (Non Reentrant) [SWS_ComM_00224]. Callers must therefore ensure at system level that no concurrent or preemptive calls occur via different tasks or interrupt service routines, in order to avoid inconsistencies when reading out the counter.

Usage and Operation

The synchronous interface ComM_ResetInhibitCounter serves to reset the internal counter for rejected or inhibited full communication requests (Inhibited COMM_FULL_COMMUNICATION request Counter) in the Communication Manager [SWS_ComM_00108]. The call is provided via the header ComM.h, has the service ID 0x0e, and requires no input parameters [SWS_ComM_00108]. Upon successful execution, the function returns the return value E_OK of type Std_ReturnType [SWS_ComM_00108].

Error Handling and Boundary Conditions

If an error occurs while resetting the counter, the service indicates this via the return value E_NOT_OK [SWS_ComM_00108]. Specific development errors (DET) or error scenarios are not listed in this specification excerpt; presumably, execution fails and returns E_NOT_OK if the module has not yet been initialized. Question Q-31d1ba95e419fa8e (open)

Concurrency

The function is declared as non-reentrant (Non Reentrant) [SWS_ComM_00108]. Users must therefore ensure through appropriate synchronization that no concurrent calls occur from multiple threads, tasks, or interrupt service routines in order to avoid inconsistencies in the counter.

Function ComM_Nm_NetworkStartIndication serves as a notification interface from the network management to the Communication Manager. According to [SWS_ComM_00383], it indicates that an NM message was received during the Bus Sleep Mode state, signaling that certain nodes in the network have already transitioned to Network Mode.

• Call and parameters: The interface is declared via header ComM_Nm.h and takes the affected communication channel Channel of type NetworkHandleType as an input parameter [SWS_ComM_00383].
• Synchronicity and return: The call has no return value (void) and follows asynchronous execution semantics [SWS_ComM_00383].
• Concurrency: The function is assigned service ID 0x15 and specified as reentrant (Reentrant) [SWS_ComM_00383].

Specific error codes, DET or DEM messages, and separate error reactions are not specified for this interface in the specification [SWS_ComM_00383]. Interpretation: The indication is presumably intended internally to initiate the transition from the sleep state to active network communication for the specified channel. Question Q-97a02db4ab6a3af8 (open)

The function ComM_Nm_NetworkMode acts in the AUTOSAR Communication Manager (ComM) as a notification callback with which the Network Management (Nm) signals that the network mode (Network Mode) has been entered successfully [SWS_ComM_00390].

Call and Parameters

The interface is available via the header file ComM_Nm.h and has the service ID 0x18 [SWS_ComM_00390]. When called, the affected communication channel is passed via the single input parameter Channel of type NetworkHandleType [SWS_ComM_00390]. The function returns no return value (return type void) and has no output parameters [SWS_ComM_00390].

Concurrency and semantics

The execution behavior of ComM_Nm_NetworkMode is declared as asynchronous (Asynchronous) [SWS_ComM_00390]. In terms of concurrency, the function is specified as reentrant (Reentrant), so that it can be called reentrantly for concurrent channel events [SWS_ComM_00390].

Error handling

Since the signature does not provide a return value, no error codes are transmitted directly to the caller [SWS_ComM_00390].

The function ComM_Nm_PrepareBusSleepMode serves as a notification interface of the Communication Manager (ComM). It informs the ComM that the Network Management for the specified communication channel has transitioned to the "Prepare Bus - Sleep Mode" state [SWS_ComM_00391].

Usage and signature

The interface is available via the header file ComM_Nm.h and has the service ID 0x19 [SWS_ComM_00391]. Execution is asynchronous [SWS_ComM_00391]. The function signature comprises the following parameters:

• Channel (In, NetworkHandleType): Identifies the affected network channel whose Network Management has entered Prepare Bus Sleep Mode [SWS_ComM_00391].
• Return value: void; no status or error values are returned and no input/output parameters are used [SWS_ComM_00391].

Concurrency and Limitations

Regarding concurrency, ComM_Nm_PrepareBusSleepMode is specified as reentrant, but with the mandatory restriction that this does not apply to the same NM channel (Reentrant (but not for the same NM - Channel)) [SWS_ComM_00391]. Calls for different channels may therefore occur concurrently, while simultaneous calls for the same channel must be excluded.

Call context and error handling

Interpretation: The call context is likely to reside in the generic or bus-specific Network Management, which reports the attainment of this state to the ComM. Question Q-41524322db480310 (open) Specific error codes, DET, or DEM messages are not defined in the specification for this interface [SWS_ComM_00391].

use

The callback function ComM_Nm_BusSleepMode serves as a notification to the ComM module that the Network Management has transitioned to Bus Sleep Mode [SWS_ComM_00392]. Through this call, the function shall execute the transition of the associated hardware as well as the transceiver to Bus Sleep Mode [SWS_ComM_00392].

Interface and parameters

The function is provided via the header file ComM_Nm.h and has the service ID 0x1a [SWS_ComM_00392]. The call is made via the signature void ComM_Nm_BusSleepMode (NetworkHandleType Channel) with the following parameter characteristics [SWS_ComM_00392]:

• Channel: Input parameter of type NetworkHandleType identifying the affected communication channel [SWS_ComM_00392].
• Neither input/output parameters nor output parameters are specified for this function [SWS_ComM_00392].
• No return value is defined (void) [SWS_ComM_00392].

Concurrency and Limitations

Regarding execution behavior and possible restrictions, the requirement specifies the following boundary conditions [SWS_ComM_00392]:

• Asynchronous Semantics: The call is classified as asynchronous (Asynchronous) [SWS_ComM_00392].
• Reentrancy: The function is defined as reentrant (Reentrant) [SWS_ComM_00392].

The callback function ComM_Nm_RestartIndication with service ID 0x1b is called by the NM interface and is declared via header file ComM_Nm.h [SWS_ComM_00792]. It serves to inform the Communication Manager about the restart of network management during an ongoing shutdown process of coordinated buses [SWS_ComM_00792]. The only input parameter Channel of type NetworkHandleType designates the affected channel; the operation does not return a return value [SWS_ComM_00792].

The interface is specified as asynchronous and reentrant [SWS_ComM_00792]. Its invocation by the NM interface occurs when three conditions are met simultaneously:

• The NM interface has already started shutting down the coordinated buses [SWS_ComM_00792].
• Not all of these coordinated buses have reported the bus sleep state yet [SWS_ComM_00792].
• Network management is restarted on at least one of the coordinated buses [SWS_ComM_00792].

If these prerequisites are met, the NM interface calls the function specifically with the handle of those channels that had already signaled the bus sleep state [SWS_ComM_00792].

Specific error codes, error reactions, or notifications to the development error tracer or diagnostic log and trace / fault memory module (DET/DEM) are not provided in the specification excerpt [SWS_ComM_00792]. Interpretation: In the ComM, the function is likely intended to realign the internal state of channels that are already sleeping with the reactivated bus coordination. Question (open)

use

Function ComM_Nm_RepeatMessageLeftIndication serves as a notification interface signaling to ComM that the state of all bus NM modules (<Bus Nm>) has left the Repeat Message state [SWS_ComM_91024]. Within the scope of the optional feature for dynamic partial network cluster-to-channel mapping (Dynamic PNC-to-channel-mapping), this call indicates that the learning phase ends [SWS_ComM_91024].

The interface is declared via header ComM_Nm.h and has no return value (void) [SWS_ComM_91024]. The affected communication channel is transmitted as an input parameter:

• Channel (In, NetworkHandleType): Identification of the channel for which leaving the state is reported [SWS_ComM_91024].

Interaction and Functional Effect

The behavior of the indication controls the PNC learning phase: If configuration parameter ComMDynamicPncToChannelMappingEnabled is set to TRUE and ComM_Nm_RepeatMessageLeftIndication is called, ComM sets the PNC learning phase (PNC Learning Phase) for the corresponding channel to inactive [SWS_ComM_01029] [SWS_ComM_01046].

Concurrency and Limitations

The interface is specified as reentrant and exhibits asynchronous execution semantics [SWS_ComM_91024]. In the present specification, the element is additionally marked with development status draft [SWS_ComM_91024].

Function ComM_Nm_PncLearningBitIndication serves as a notification interface for module ComM to indicate the reception of an NM message with the PNC learning bit set [SWS_ComM_91026]. The interface has service ID 0x69, is provided via header file ComM_Nm.h, and is marked with \"draft\" status in the specification [SWS_ComM_91026].

With regard to usage and signature, the following specifications apply:

• Parameters: Channel of type NetworkHandleType is passed as an input parameter, identifying the affected communication channel [SWS_ComM_91026]. There are neither input/output nor output parameters, and the return type is void [SWS_ComM_91026].
• Concurrency: The call is specified as asynchronous and reentrant [SWS_ComM_91026]. According to the identifier and header, the call is presumably typically made by the underlying NM module as soon as a corresponding NM message has been received. Question Q-31b0ce30b88c71b6 (open)
• Error handling: In the scope of the specification, neither return values nor specific error codes or messages to DET or DEM are documented for this service.

In interaction with dynamic PNC mapping, the function controls the activation of the learning phase: If ComM_Nm_PncLearningBitIndication is called on a channel for which configuration parameter ComMDynamicPncToChannelMappingEnabled is set to TRUE, ComM must set the PNC learning phase (PNC Learning Phase) for this channel to active [SWS_ComM_01026]. According to the specification, ComM also triggers the same state of an active learning phase on the channel in question when the module itself calls Nm_PnLearningRequest [SWS_ComM_01026].

The synchronous and reentrant function ComM_Nm_ForwardSynchronizedPncShutdown (service ID 0x6b) is declared via header ComM_Nm.h and serves the coordinated forwarding of a synchronized PNC shutdown [SWS_ComM_91003].

Usage and call context: It is called when an ECU in the role of an intermediate PNC coordinator receives a PN shutdown message via a bus-specific NM [SWS_ComM_91003]. The affected communication channel (Channel of type NetworkHandleType) is passed as the only input parameter. A return value is not defined (void) [SWS_ComM_91003].

Interaction and sequence: Following the indication, the ComM immediately releases the affected PNC state machines. In addition, it forwards the PN information directly to the affected ComM channels as well as the corresponding NM channels [SWS_ComM_91003]. This ensures a largely synchronous PNC shutdown across the hierarchical PN topology from the higher-level top-level coordinator down to the subordinate PNC nodes [SWS_ComM_91003].

Error handling and constraints: Because the interface has no return value and no specific error codes are documented, error handling is presumably performed internally or via the DET. Question Q-618a8c1da055cdf5 (open) The element is classified as Draft in release R20-11 [SWS_ComM_91003].

Usage and Call Context

The synchronous interface ComM_DCM_ActiveDiagnostic is used by the Diagnostic Communication Manager (DCM) to notify the Communication Manager (ComM) about active diagnostic activities on a specific communication channel [SWS_ComM_00873]. The function is defined in the header file ComM_Dcm.h and identified by service ID 0x1f [SWS_ComM_00873].

The only call parameter is input parameter Channel of data type NetworkHandleType, which uniquely identifies the affected channel for the upcoming diagnostic communication [SWS_ComM_00873]. The interface has no return value (return type void), and there are neither input/output nor output parameters [SWS_ComM_00873].

Concurrency and Limitations

Regarding concurrency, the service element is specified as reentrant [SWS_ComM_00873]. This allows parallel synchronous calls of the function from different execution contexts, for instance if the DCM has to manage or serve multiple network channels concurrently.

Error Handling and Interaction

No separate error codes or notifications to development error management (DET) or diagnostic event manager (DEM) are specified for this call [SWS_ComM_00873]. The interaction is limited to signal exchange between DCM and ComM; interpretation: The call is likely used in ComM to keep the corresponding channel in the active communication state for the duration of the diagnostic activity [SWS_ComM_00873]. Question Q-bfd91da2e435fbb6 (open)

use

The synchronous function ComM_DCM_InactiveDiagnostic serves the Diagnostic Communication Manager (DCM) to indicate to the Communication Manager (ComM) that diagnostic communication on a specific channel is inactive and no longer needed [SWS_ComM_00874]. The declaration of this interface is provided via header file ComM_Dcm.h with service ID 0x20 [SWS_ComM_00874].

Channel of type NetworkHandleType is passed as an input parameter, which identifies the communication channel concerned [SWS_ComM_00874]. The function has neither input/output parameters nor output parameters and returns no value (void) [SWS_ComM_00874].

Concurrency and Error Handling

The interface is specified as reentrant [SWS_ComM_00874], so that concurrent calls—such as for different communication channels—are permissible. Specific error codes, DET error reports, or DEM events are not defined for this function in the payload [SWS_ComM_00874]. The ComM module is expected to use the inactivity notification internally to cancel existing diagnostic requests for the channel and adjust the channel status accordingly. Question Q-148d39d8c17e936c (open)

The function ComM_EcuM_WakeUpIndication serves to notify the Communication Manager (ComM) of a wake-up event that occurred on the affected communication channel [SWS_ComM_00275]. The call is typically likely to be made by the ECU State Manager (EcuM) as soon as it has registered a corresponding wake-up on a channel. Question Q-5f8c43b9df10dc8e (open)

Usage and Call Context

The interface is defined as synchronous and has the service ID 0x2a [SWS_ComM_00275]. The identifier of the communication channel on which the wake-up was detected is passed via the input parameter Channel of type NetworkHandleType [SWS_ComM_00275]. The function has no return value (void) and is declared via the header file ComM_EcuM.h [SWS_ComM_00275].

Concurrency and Limitations

According to the specification, ComM_EcuM_WakeUpIndication is classified as reentrant [SWS_ComM_00275]. Thus, the function may be called concurrently for different channels or from concurrent contexts. Specific error codes, return values, or DET/DEM messages are not indicated in the element definition [SWS_ComM_00275].

Usage and Call Context

The synchronous function ComM_EcuM_PNCWakeUpIndication serves to notify the Communication Manager about a wake-up on a Partial Network Cluster (PNC) [SWS_ComM_91001]. It is declared via header ComM_EcuM.h and expects the identifier of the affected cluster as input parameter PNCid; return values do not exist [SWS_ComM_91001]. Interpretation: The call typically occurs through the ECU State Manager (EcuM) upon detection of a corresponding PNC event. Question Q-fee4a70f73cde8ea (open)

Concurrency and State Transitions

The interface is specified as reentrant [SWS_ComM_91001]. Calling it causes targeted state changes within the PNC and channel state machines of the ComM:

• If the referenced cluster is in PNC main state PNC_NO_COMMUNICATION, this state is exited and a transition to PNC sub-state PNC_PREPARE_SLEEP is made [SWS_ComM_00964].
• If the call occurs in sub-state COMM_NO_COM_NO_PENDING_REQUEST with enabled PNC support (ComMPncSupport=TRUE) and disabled synchronous wake-up (ComMSynchronousWakeUp=FALSE), the module transitions those ComM channel state machines to sub-state COMM_NO_COM_REQUEST_PENDING that are referenced by the specified PNC [SWS_ComM_01014].
• If, on the other hand, ComMSynchronousWakeUp=TRUE is configured with active ComMPncSupport, the call in sub-state COMM_NO_COM_NO_PENDING_REQUEST switches all ComM channel state machines without exception to sub-state COMM_NO_COM_REQUEST_PENDING [SWS_ComM_01015].

Via the function ComM_CommunicationAllowed ([SWS_ComM_00871]), EcuM or BswM indicates to the ComM module whether communication is allowed for a specific channel.

Usage and Call Context

The interface is called by module EcuM or BswM; if EcuM Flex is used, BswM takes over this task ([SWS_ComM_00871]). The function is declared via the header ComM_BswM.h and has service ID 0x35 ([SWS_ComM_00871]).

The function has no return value (void) and expects the following parameters ([SWS_ComM_00871]):

• Channel (type NetworkHandleType): Designates the affected communication channel ([SWS_ComM_00871]).
• Allowed (type boolean): Passes the permission status with TRUE for allowed communication or FALSE for communication not allowed ([SWS_ComM_00871]).

Concurrency and Limitations

According to the specification, the function operates asynchronously (Asynchronous) and is classified as non-reentrant (Non Reentrant) ([SWS_ComM_00871]). Due to non-reentrancy, the caller presumably must ensure that no parallel or preemptive calls occur for the interface. Question Q-e6688e3286d9ed60 (open)

Usage and signature

The interface ComM_BusSM_ModeIndication serves to indicate the actual bus mode by the responsible Bus State Manager to the module ComM [SWS_ComM_00675]. The C function is available via header ComM.h and is listed under service ID 0x33 [SWS_ComM_00675]. Its syntax is void ComM_BusSM_ModeIndication (NetworkHandleType Channel, ComM_ModeType ComMode) [SWS_ComM_00675].

The function accepts two input parameters:

• Channel: The affected communication channel of type NetworkHandleType [SWS_ComM_00675].
• ComMode: The actual mode of the bus of type ComM_ModeType [SWS_ComM_00675].

The interface has no return value (void) and defines neither input/output parameters nor pure return parameters [SWS_ComM_00675].

Concurrency and Synchronization

For the runtime behavior, it is specified that the call is asynchronous (Asynchronous) and the function can be executed reentrantly (Reentrant) [SWS_ComM_00675].

Interaction in the Overall System

The module ComM forwards the state reported via this call to the users [SWS_ComM_00675]. This propagation of the bus state is performed via the interfaces of the RTE and the BswM [SWS_ComM_00675].

use

The synchronous service function ComM_BusSM_BusSleepMode serves the responsible Bus State Manager (BusSM) as a notification to the Communication Manager (ComM) that the actual bus mode of a communication channel has changed to the bus sleep state [SWS_ComM_91000]. The affected channel is identified via input parameter Channel of type NetworkHandleType [SWS_ComM_91000]. The function declares neither output parameters nor a return value (void) [SWS_ComM_91000].

Configuration-dependent validity

The call is not universally permissible, but explicitly restricted to ComM channels whose parameter ComMNmVariant is set to SLAVE_ACTIVE or SLAVE_PASSIVE [SWS_ComM_91000]. The specification names two typical application scenarios for this:

• LIN slaves with configuration ComMNmVariant = SLAVE_ACTIVE [SWS_ComM_91000].
• Ethernet channels with hardware according to OPEN Alliance TC10 operated as passive communication slaves, where ComMNmVariant = SLAVE_PASSIVE and parameter EthTrcvActAsSlavePassiveEnabled is set to TRUE [SWS_ComM_91000].

Concurrency and Integration

The interface has service ID 0x34, is declared via header file ComM.h, and is classified as reentrant [SWS_ComM_91000]. Specific error codes or a dedicated behavior in case of error are not specified in the function definition [SWS_ComM_91000].

The enumeration type ComM_InitStatusType serves to represent the initialization status of the module ComM (COM Manager) and is available via the header file ComM.h [SWS_ComM_00668].

The value range comprises exactly two states to distinguish operational readiness [SWS_ComM_00668]:

• COMM_UNINIT (encoded with the value 0x00 or 0): Indicates that the COM Manager is not initialized or not usable. This state is mandatorily the default value directly after a reset [SWS_ComM_00668].
• COMM_INIT (encoded with the value 0x01): Indicates that the COM Manager has been properly initialized and is operational [SWS_ComM_00668].

Regarding temporal order and module usage, this status marks the fundamental usability of the COM Manager [SWS_ComM_00668]. Interpretation: Callers or internal module routines are expected to evaluate this status to ensure that no communication requests are processed in state COMM_UNINIT, since the COM Manager is explicitly specified as not usable in this state [SWS_ComM_00668]. Question Q-2c4da2e5c40a0f4b (open) Only after the successful transition to COMM_INIT is the module available for higher-level interactions.

The enumeration type ComM_PncModeType defines the current operating state of a Partial Network Cluster (PNC) in the Communication Manager [SWS_ComM_00673]. The type is provided via the header file ComM.h and comprises five discrete states [SWS_ComM_00673]:

• COMM_PNC_REQUESTED (0x00): The PNC is requested by a local ComM user.
• COMM_PNC_READY_SLEEP (0x01): The PNC is requested by a remote ComM user.
• COMM_PNC_PREPARE_SLEEP (0x02): The PNC is active, but without deadline monitoring.
• COMM_PNC_NO_COMMUNICATION (0x03): No communication takes place for the PNC.
• COMM_PNC_REQUESTED_WITH_WAKEUP_REQUEST (0x04): Local PNC request with an additional request for hardware wake-up to the BswM.

In interaction with the BswM, mode COMM_PNC_REQUESTED_WITH_WAKEUP_REQUEST serves to signal that an active request shall additionally trigger the wake-up of the communication hardware [SWS_ComM_00673]. This requires that the feature is supported and configured, for example during port switching of Ethernet switches according to OA TC10 [SWS_ComM_00673]. As a restriction, it must be noted that this mode has the status draft in release R20-11 [SWS_ComM_00673].

Since this is a pure type definition, no dedicated error handling routines or reentrancy requirements exist for ComM_PncModeType.

Interpretation: Since the type is declared in ComM.h and the BswM is addressed as the receiver of the mode information, the data type is likely used across modules as an interface parameter for PNC status notifications. Question Q-88ad945ffcf90e9e (open)

Usage and definition

The type ComM_StateType represents the states and sub-states of the internal state machine of the Communication Manager (ComM) in the AUTOSAR Classic Platform [SWS_ComM_00674]. It is defined as a separate type based on standard type uint8 and is provided via the header file ComM.h for software components and BSW modules [SWS_ComM_00674].

Value Range and Sub-States

The value range comprises five defined values, which map the exact phase of the communication state machine [SWS_ComM_00674]:

• COMM_NO_COM_NO_PENDING_REQUEST (value 0): Designates the state within No Communication when no communication request is currently present [SWS_ComM_00674].
• COMM_NO_COM_REQUEST_PENDING (value 1): Designates the state within No Communication while a request for communication is pending [SWS_ComM_00674].
• COMM_FULL_COM_NETWORK_REQUESTED (value 2): Designates the state within Full Communication in which the network is actively requested [SWS_ComM_00674].
• COMM_FULL_COM_READY_SLEEP (value 3): Designates the state within Full Communication in which no active requests are present anymore and the network is ready to sleep [SWS_ComM_00674].
• COMM_SILENT_COM (value 4): Corresponds to the communication mode Silent Communication [SWS_ComM_00674].

Mapping to Communication Modes

The values of ComM_StateType have a direct relation to the higher-level communication modes of the ComM [SWS_ComM_00674]. All states with the prefix COMM_NO_COM* are assigned to the mode No Communication, whereas states with the prefix COMM_FULL_COM* correspond to the mode Full Communication [SWS_ComM_00674]. The value COMM_SILENT_COM maps the communication mode of the same name, Silent Communication [SWS_ComM_00674].

The data type ComM_ModeType represents the current communication mode and thus the primary state of the ComM channel state machine in the Communication Manager [SWS_ComM_00672]. It is derived from base type uint8 and is provided via header Rte_ComM_Type.h for use by software components and other BSW modules [SWS_ComM_00672].

The value range comprises four discrete operating modes that define the communication capability of the respective channel [SWS_ComM_00672]:

• COMM_NO_COMMUNICATION (0): The configured channel is in the quiet state and has neither transmission nor reception capability [SWS_ComM_00672].
• COMM_SILENT_COMMUNICATION (1): The channel is restricted to passive reception capability; sending of messages is prevented [SWS_ComM_00672].
• COMM_FULL_COMMUNICATION (2): The channel is in full communication mode with active transmission and reception capability [SWS_ComM_00672].
• COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST (3): The channel has transmission and reception capability to the lower layer, for example for Ethernet hardware according to OPEN Alliance TC10 [SWS_ComM_00672].

Essential functional restrictions apply during usage: Mode COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST is provided with the tag atp.Status=draft and is expressly intended for purely internal use within the ComM channel state machine [SWS_ComM_00672]. External users or superimposed software components are therefore presumably not permitted to request this state as a target mode nor to expect it directly via interfaces. Question Q-e5f4abe0d6543c82 (open) Specific error codes, runtime checks, or notifications to DET or DEM are not defined for this type [SWS_ComM_00672].

The specification element modeLimitation is defined according to [SWS_ComM_01009] as a provided port of the Communication Manager (ComM) for interface ComM_ECUModeLimitation. Interpretation: Via this port interface, module ComM is likely to provide higher-level software components or the BswM with mechanisms for the targeted limitation of active communication modes at the ECU level, for example to safeguard power consumption or operating modes. Question Q-337c6b40bd72cf76 (open)

The provision of this port in the system is subject to an explicit variability condition: according to [SWS_ComM_01009], the element is present in the system only if the configuration option {ecuc(ComM/ComMGeneral.ComMModeLimitationEnabled)} == true is set. Disabling this parameter presumably causes the port to be omitted during code generation. Question (open) Application and basic software components may therefore architecturally bind this interface only when the option is enabled.

Regarding concrete interface operations, parameters, reentrancy, and error reports to DET or DEM, [SWS_ComM_01009] contains no special definitions. Integrators must therefore primarily ensure that the required configuration is enabled in container ComMGeneral before components are connected to port modeLimitation.

The type ComMMode is specified in module ComM as a Mode Declaration Group [SWS_ComM_01012]. The element is assigned to category ALPHABETIC_ORDER and defines the fundamental communication modes of the module [SWS_ComM_01012].

The group comprises three mandatory states [SWS_ComM_01012]:

• COMM_NO_COMMUNICATION: Serves as the initial mode of the group [SWS_ComM_01012].
• COMM_SILENT_COMMUNICATION: Represents a passive communication mode [SWS_ComM_01012].
• COMM_FULL_COMMUNICATION: Identifies unrestricted communication operation [SWS_ComM_01012].

COMM_NO_COMMUNICATION is defined as the initial mode, meaning the system starts by default without active communication [SWS_ComM_01012]. No separate value ("On transition value") is defined for transitions [SWS_ComM_01012]; Interpretation: This presumably means that state changes are performed directly without defined intermediate states. Question Q-f0e73d26f85073b4 (open) Interpretation: The modes are expected to represent the communication state of channels or communication users in the module. Question Q-ef5fa29f6af152c7 (open) Interpretation: Category ALPHABETIC_ORDER is primarily expected to specify the standardized enumeration and representation for the interfaces of the RTE. Question Q-12af3dde3a4cc95e (open)