Diagnostic Communication Manager (DCM)

The synchronous and non-reentrant function Dcm_Init serves the fundamental initialization of the DCM module [SWS_Dcm_00037]. Via the parameter ConfigPtr, it accepts a pointer to the configuration set in post-build variants and has no return value [SWS_Dcm_00037]. During execution, the module initializes all global DCM variables with the values from the configuration [SWS_Dcm_00334].

As part of the initialization sequence, various functional areas and states are configured:

• DDDID management: If the configuration parameter DcmDDDIDStorage is set to FALSE, the DCM initializes all dynamically defined data identifiers (DDDIDs) as not present during startup [SWS_Dcm_00866]. If the parameter is set to TRUE, the DDDID definitions are restored from the NvM [SWS_Dcm_00867].
• Response on Event (ROE): The DCM transitions the state of each event during Dcm_Init into the status 'ROE cleared' [SWS_Dcm_00872].
• Authentication status: If DcmDspAuthenticationPersistStateModeRuleRef is not configured or the referenced mode rule evaluates to false, the module sets all authentication states to the state 'deauthenticated' [SWS_Dcm_01480].
• Communication status: After completion of Dcm_Init, the DCM sets the parameter ActiveDiagnostic to 'DCM_COMM_ACTIVE' [SWS_Dcm_01069].

Regarding the execution environment, it is specified that Dcm_Init is non-reentrant [SWS_Dcm_00037]. Specific error codes and standardized error messages to DET or DEM are not identified for this initialization service in the interface specification [SWS_Dcm_00037].

use

The synchronous interface Dcm_DemTriggerOnDTCStatus (Service ID 0x2B) is available via the header Dcm_Dem.h and serves to report changes to the UDS status byte to the DCM [SWS_Dcm_00614]. This allows the DCM to trigger response-on-event (ROE) events for the diagnostic service subservice OnDTCStatusChanged [SWS_Dcm_00614]. When called, the function accepts three input parameters: the affected error code DTC (uint32), the previous state DTCStatusOld (Dem_UdsStatusByteType), and the updated state DTCStatusNew (Dem_UdsStatusByteType) [SWS_Dcm_00614]. Input/output parameters do not exist [SWS_Dcm_00614].

Return Values and Error Handling

As return value, the function provides the type Std_ReturnType, whereby according to the specification E_OK is returned without exception [SWS_Dcm_00614]. Specific error codes, fallback values, or separate notifications to DEM or DET are not indicated for this call.

Concurrency and Interaction

The function is classified as reentrant and possesses synchronous execution semantics [SWS_Dcm_00614]. Regarding interaction with diagnostic requests, a fixed constraint applies: If a request to clear the event memory (EventMemory) is currently being processed in the DCM, the DCM must ignore incoming calls of the callback Dcm_DemTriggerOnDTCStatus [SWS_Dcm_01410].

The function Dcm_BndMWriteBlockFinish serves as a notification interface from the BndM to the DCM to indicate the completion of a block write operation [SWS_Dcm_91088]. The function is declared in header file Dcm.h, has the service ID 0x7a, provides no return value (void), and is executed synchronously [SWS_Dcm_91088].

The interface expects two passing parameters [SWS_Dcm_91088]:

• BlockId (type: BndM_BlockIdType): Identifies the block whose write operation has been completed.
• result (type: BndM_ResultType): Transmits the result of the write operation to the DCM.

The functional interaction and the error handling behavior are coupled to atomic BndM write operations previously initiated by the DCM:

• If Dcm_BndMWriteBlockFinish is called with status result = E_OK, the DCM sends a positive diagnostic response to the pending request [SWS_Dcm_01584].
• If the function is called with result = E_NOT_OK, the DCM reacts with a negative diagnostic response 0x72 (generalProgrammingFailure) in case of an error [SWS_Dcm_01585].

Regarding concurrency, Dcm_BndMWriteBlockFinish is specified as non-reentrant (Non Reentrant) [SWS_Dcm_91088]. Callers must therefore ensure that the function is not called concurrently or preemptively by multiple contexts.

Usage and Call Context

The function Dcm_SetDeauthenticatedRole is executed synchronously and reentrantly ([SWS_Dcm_91069]). It allows a software component to assign a new role deauthenticatedRole of type Dcm_AuthenticationRoleType for the deauthenticated state to a connection identified by connectionId ([SWS_Dcm_91069], [SWS_Dcm_01486]). The return value is invariably E_OK ([SWS_Dcm_91069]).

State Conditions and Error Handling

A call is processed by the DCM only if the connection is in the deauthenticated state (deauthenticated state) ([SWS_Dcm_01487]). Since the signature provides no alternative error values and always returns E_OK ([SWS_Dcm_91069]), a call outside this state is presumably discarded without an error message. Question Q-6f14770eae6ce896 (open) Specific DET or DEM events are not defined in the specification.

Period of Validity and Lifecycle

If the role for the deauthenticated state is accepted successfully ([SWS_Dcm_01486]), this assignment persists temporarily:

• The set role is discarded as soon as the connection transitions to the authenticated state (authenticated state) ([SWS_Dcm_01488]).
• Validity ends at the latest upon a reset of the ECU ([SWS_Dcm_91069]).

The synchronous and reentrant function Dcm_GetSecurityLevel queries the currently active security level of the DCM and provides it [SWS_Dcm_00338]. The function is declared via the header Dcm.h and passes the determined status value to the caller via the output parameter SecLevel of type Dcm_SecLevelType*. According to the specification, E_OK is returned without exception [SWS_Dcm_00338].

The determination of the internal security level is based on the parameter SecurityAccessType transmitted by the tester as part of the service SecurityAccess according to the fixed conversion formula SecurityLevel = (SecurityAccessType + 1) / 2 [SWS_Dcm_00338].

In interaction with higher-level diagnostic service processing, the DSP submodule, among others, accesses this value: If the module receives a configured request with the subfunction type “requestSeed” (odd value) and the associated access level is already active according to Dcm_GetSecurityLevel, the DSP submodule sets the seed content to 0x00 [SWS_Dcm_00323].

Regarding concurrency and error handling, the function is defined as reentrant [SWS_Dcm_00338]. Since no specific error codes or DET checks are specified and E_OK is always returned, no null-pointer check is likely performed; callers must therefore presumably always pass a valid pointer to memory for SecLevel. Question Q-5402d82ac0151b22 (open)

The synchronous function Dcm_ResetToDefaultSession allows the application to reset the active diagnostic session to the default session [SWS_Dcm_00520]. A typical use case is the automatic termination of an extended diagnostic session as soon as a vehicle exceeds a predefined speed threshold [SWS_Dcm_00520].

Usage and Error Handling

• Interface and parameters: The function is available via Dcm.h with service ID 0x2a, has the signature Std_ReturnType Dcm_ResetToDefaultSession (void), and requires no passed parameters [SWS_Dcm_00520].
• Return value and errors: Std_ReturnType is returned as the return type, returning the value E_OK without exception [SWS_Dcm_00520]. Specific error codes, DET runtime checks, or DEM events are not specified in the requirements for this call.

Concurrency and Interaction

Execution is synchronous and declared as reentrant [SWS_Dcm_00520].

In addition to the actual session change, Dcm_ResetToDefaultSession mandatorily initiates a mode change for the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl [SWS_Dcm_01062]. In doing so, the function internally calls SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnosticSessionControl_DCM_DEFAULT_SESSION) to notify the system environment about the transition to the default session [SWS_Dcm_01062].

The synchronous function Dcm_TriggerOnEvent (service ID 0x2D), provided via the header Dcm.h, serves to trigger an event linked to a ResponseOnEvent request (ROE) [SWS_Dcm_00521].

Call and Operation

The caller passes RoeEventId (input parameter of type uint8) as the only parameter, which identifies the event to be triggered; in/out or output parameters do not exist [SWS_Dcm_00521]. As soon as the function is called, the DCM checks the state of the event: if the passed RoeEvent is active, the DCM triggers the corresponding event [SWS_Dcm_00920]. The DCM executes the service associated with the event provided that the associated mode of the RoeEventId is set to 'ROE started' [SWS_Dcm_00521].

Return Values and Validation

The call synchronously returns a status of type Std_ReturnType providing information about the validity of the parameter [SWS_Dcm_00521]:

• E_OK: The passed value for RoeEventId is valid [SWS_Dcm_00521].
• E_NOT_OK: The value of RoeEventId is invalid [SWS_Dcm_00521].

Concurrency and Properties

The interface is specified as reentrant [SWS_Dcm_00521]. It can therefore be called concurrently to report events synchronously to the DCM [SWS_Dcm_00521].

The synchronous and reentrant function Dcm_StartOfReception ([SWS_Dcm_00094]) is called by a transport protocol module at the start of receiving an N-SDU—both for single frames (SF) and for segmented messages (First Frame, FF). It can be called in interrupt context ([SWS_Dcm_00094]). Among other things, the call causes the S3Server timer to stop at the start of reception ([SWS_Dcm_00141]).

Payload data and metadata are passed via info; for generic connections, this is used, among other things, to store SOURCE_ADDRESS_16 ([SWS_Dcm_00848]) and check TARGET_ADDRESS_16 ([SWS_Dcm_01347]). If neither payload nor metadata is present, NULL_PTR is passed ([SWS_Dcm_00094]). Via bufferSizePtr, the function reports back the available buffer for calculating the Block Size (BS) ([SWS_Dcm_00094]). Upon successful acceptance, it returns BUFREQ_OK, whereupon subsequent data is copied via Dcm_CopyRxData ([SWS_Dcm_00443]).

Error and rejection cases are signaled via the return value:

• BUFREQ_E_OVFL: Returned if the requested length TpSduLength is greater than the buffer available in the DCM ([SWS_Dcm_00094], [SWS_Dcm_00444]). bufferSizePtr remains unchanged ([SWS_Dcm_00094]).
• BUFREQ_E_NOT_OK: Returned if TpSduLength is equal to 0 ([SWS_Dcm_00642]) or an ongoing request on the same connection is blocking ([SWS_Dcm_00557]). For another connection, the parameter DcmDslDiagRespOnSecondDeclinedRequest decides whether it is rejected with BUFREQ_E_NOT_OK ([SWS_Dcm_00790]) or accepted with BUFREQ_OK ([SWS_Dcm_00788]). Concurrent TesterPresent requests are likewise acknowledged with BUFREQ_OK ([SWS_Dcm_00557]).

use

The synchronous function Dcm_CopyRxData is called to pass received data of an I-PDU segment (N-PDU) to the upper layer in the DCM [SWS_Dcm_00556]. Each call provides the next part of the I-PDU data [SWS_Dcm_00556]. The received I-PDU is identified via the parameter id [SWS_Dcm_00556]. The pointer info provides the source buffer via SduDataPtr and the number of bytes to be copied via SduLength [SWS_Dcm_00556]. After completion of the copy process, the remaining free buffer size in the DCM is returned via bufferSizePtr [SWS_Dcm_00556], [SWS_Dcm_00443].

If Dcm_CopyRxData is called with an SduLength of 0, this serves purely for buffer querying [SWS_Dcm_00556]. In this case, SduDataPtr may be a NULL_PTR; the function returns BUFREQ_OK and enters the remaining size of the receive buffer into bufferSizePtr [SWS_Dcm_00556], [SWS_Dcm_00996].

Interaction

Prior to copying, Dcm_StartOfReception must have been completed with BUFREQ_OK; subsequent calls of Dcm_CopyRxData copy the data from the provided buffer into the DCM buffer and update bufferSizePtr [SWS_Dcm_00443].

Error handling

The function returns the status as BufReq_ReturnType: BUFREQ_OK confirms the successful copying or the buffer query, while BUFREQ_E_NOT_OK indicates that no data was copied due to an error [SWS_Dcm_00556], [SWS_Dcm_00996].

Concurrency and Limitations

Dcm_CopyRxData is specified as reentrant and may be called in interrupt context [SWS_Dcm_00556]. The interface is provided via Dcm.h [SWS_Dcm_00556].

Usage and Call Context

The synchronous function Dcm_TpRxIndication is called after reception of an I-PDU via the TP API, typically by the module PduR [SWS_Dcm_00093], [SWS_Dcm_00112]. It passes the PDU identification (id) as well as the reception result (result) and returns no return value [SWS_Dcm_00093]. Since the function is reentrant and may be called in interrupt context, caller and module states must be designed for corresponding concurrency [SWS_Dcm_00093].

Behavior on Erroneous Reception

If Dcm_TpRxIndication is called with a result value that differs from E_OK, the module Dcm must not evaluate the buffer assigned to the referenced I-PDU [SWS_Dcm_00344].

Interaction of the Submodules

The DSL submodule forwards received data to the DSD submodule exclusively if the call was made with the parameter value result = E_OK [SWS_Dcm_00111]. Specific rules apply to diagnostic requests:

• If the successfully received request (Result = E_OK) is the command TesterPresent with suppressPosRspMsgIndicationBit set (SID 0x3E, subfunction 0x80), the DSL submodule resets the session timeout timer S3Server [SWS_Dcm_00112].
• In this case, the request is not forwarded by the DSL submodule to the DSD submodule for further interpretation [SWS_Dcm_00113].

Usage and Semantics

The synchronous and reentrant function Dcm_CopyTxData is called by lower-layer modules (such as transport protocols) to retrieve data of an I-PDU segment (N-PDU) for transmission [SWS_Dcm_00092]. Via the parameter info, the caller passes the destination buffer SduDataPtr and the requested byte length SduLength. A value of 0 for SduLength can be used to signal status changes via retry or to query the amount of available data; in this case, SduDataPtr may be a NULL_PTR [SWS_Dcm_00092]. Via availableDataPtr, the DCM reports the remaining number of bytes in the transmit buffer, which can be used by TP modules to determine subsequent segment sizes and must not exceed the number of bytes still to be sent [SWS_Dcm_00092], [SWS_Dcm_00350].

Buffer Management and Transmission Retry

Acknowledgment or retry of data is controlled via the parameter retry [SWS_Dcm_00092]:

• If retry is a NULL_PTR, the data may be removed from the buffer immediately after the copy process [SWS_Dcm_00092].
• With TP_CONFPENDING, previously copied data must remain in the TP buffer for potential error recovery [SWS_Dcm_00092].
• TP_DATACONF confirms all data copied prior to this call for release [SWS_Dcm_00092].
• TP_DATARETRY recopies data starting from the offset TxTpDataCnt relative to the current position [SWS_Dcm_00092].

Return Values and Error Handling

If the data was copied successfully and completely, the function returns BUFREQ_OK [SWS_Dcm_00092], [SWS_Dcm_00346]. If not enough transmit data is available, no copy process is performed and BUFREQ_E_BUSY is returned; the lower layer can repeat the call later [SWS_Dcm_00092]. If the request fails, the function returns BUFREQ_E_NOT_OK [SWS_Dcm_00092]. In this case, the transmit request from PduR_DcmTransmit() is not yet completed; only a concluding call of Dcm_TpTxConfirmation terminates the process and enables new transmissions [SWS_Dcm_00350].

Concurrency

The function is reentrant and may also be called in interrupt context [SWS_Dcm_00092].

The callback function Dcm_TpTxConfirmation ([SWS_Dcm_00351]) is called synchronously by the lower transport layer after a diagnostic I-PDU has been transmitted on the network. The affected I-PDU is identified via the parameter id, while result reports the success or failure of the transmission process ([SWS_Dcm_00351]). The function has no return value, is reentrant, and may explicitly be executed in interrupt context ([SWS_Dcm_00351]).

When Dcm_TpTxConfirmation is called, the DCM module performs central cleanup and state transitions:

• The assigned transmit buffer is unlocked ([SWS_Dcm_00352]).
• Running error monitorings such as page buffer timeouts as well as P2ServerMax and P2*ServerMax timeouts are stopped ([SWS_Dcm_00353]).
• The DcmPduId of the connection, which had been locked since reception (Dcm_TpRxIndication), is released so that subsequent requests can be received ([SWS_Dcm_00241]).
• The active protocol is not terminated by the confirmation of the DSL response (no call of xxx_StopProtocol) ([SWS_Dcm_00624]).

In the event of an error (if result indicates an error or an abort after a failed Dcm_CopyTxData is confirmed), [SWS_Dcm_00350] mandatorily requires this final call in order to formally conclude the transmission order and enable new transmissions via PduR_DcmTransmit(). Upon an erroneous confirmation, the DSD submodule must not retransmit the diagnostic response ([SWS_Dcm_00118]).

In addition, confirmation of a response (other than NRC 0x78) marks the regular completion of a diagnostic request ([SWS_Dcm_01378]). Following confirmation of a positive response to a EcuReset, the DCM ignores all further requests during reset processing ([SWS_Dcm_00834]).

use

According to [SWS_Dcm_01092], the synchronous interface Dcm_TxConfirmation (service ID 0x40, declared in Dcm.h) is called by the underlying communication interface module to confirm the transmission of a PDU or to report the failure of the transmission. The function has no return value and processes two input parameters:

• TxPduId: Identifier (PduIdType) of the transmitted PDU.
• result: Status of the transmission (Std_ReturnType). Valid values are E_OK in the case of successful transmission and E_NOT_OK if the transmission of the PDU failed.

Error Handling and Status Feedback

The result of the transmission is signaled directly to the DCM via the parameter result ([SWS_Dcm_01092]). Specific DET or DEM error messages are not defined for this function in the provided specification excerpt.

Concurrency and Call Context

Regarding reentrancy, Dcm_TxConfirmation is reentrant for calls with different PDU IDs, but not reentrant for the same TxPduId ([SWS_Dcm_01092]). It should be noted that the call by the underlying module can take place in the interrupt context ([SWS_Dcm_01092]).

Interaction

In the case of a periodic transmission (PeriodicTransmission), the DCM is called according to [SWS_Dcm_01073] via Dcm_TxConfirmation to be notified of the respective transmission result.

The synchronous and reentrant function Dcm_ComM_NoComModeEntered (service ID 0x21) informs the DCM module about the transition of a communication network to the state COMM_NO_COMMUNICATION [SWS_Dcm_00356]. The interface is provided via the header Dcm_ComM.h, has no return value, and identifies the affected network via the input parameter NetworkId of type uint8 [SWS_Dcm_00356].

With this call, the DCM shuts down any communication on the specified network, completely disabling both reception and transmission of messages [SWS_Dcm_00148]. This mandatorily includes the following transmission types:

• suppression of ResponseOnEvent transmissions [SWS_Dcm_00149],
• deactivation of periodic transmissions via ReadDataByPeriodicIdentifier (periodicId) [SWS_Dcm_00150], and
• shutdown of normal transmissions [SWS_Dcm_00151].

Consequently, following execution of Dcm_ComM_NoComModeEntered, the DCM module must no longer call the PduR function PduR_DcmTransmit() for this context [SWS_Dcm_00152].

If the function is called with a NetworkId that does not correspond to any ComM channel referenced in the DCM via configuration parameter DcmDslProtocolComMChannelRef, the DCM module does not perform any actions and returns immediately [SWS_Dcm_01324].

The synchronous and reentrant function Dcm_ComM_SilentComModeEntered ([SWS_Dcm_00358]) serves to inform the DCM module about the transition of a communication network to the state COMM_SILENT_COMMUNICATION. The interface has the service ID 0x22, provides no return value, and expects the identifier of the affected network as input parameter NetworkId ([SWS_Dcm_00358]). It is provided via the header file Dcm_ComM.h ([SWS_Dcm_00358]).

As soon as this call occurs, the DCM must completely stop all transmission activities on the affected network channel ([SWS_Dcm_00153]). In detail, this includes the following measures:

• deactivation of all normal transmissions ([SWS_Dcm_00156]),
• suppression of response-on-event transmissions ([SWS_Dcm_00154]), and
• deactivation of periodic transmissions in the context of ReadDataByPeriodicIdentifier ([SWS_Dcm_00155]).

Regarding error handling and boundary conditions, it is specified that the DCM must return without any further action if the passed NetworkId corresponds to a ComM channel that is not referenced in the DCM via configuration parameter DcmDslProtocolComMChannelRef ([SWS_Dcm_01325]). Specific development errors or error return values are not specified for this call.

Interpretation: The call is typically expected to be made by the ComM module as soon as the transition into silent communication mode is carried out. Question Q-fc9b6303ae0c0e41 (open)

The synchronous and reentrant function Dcm_ComM_FullComModeEntered is provided via the header file Dcm_ComM.h and informs the DCM module about the transition of a communication network into the state COMM_FULL_COMMUNICATION [SWS_Dcm_00360]. Input parameter NetworkId serves to identify the network affected by the mode change [SWS_Dcm_00360].

The call activates any communication for this network, enabling both message reception and transmission [SWS_Dcm_00157]. This includes the following transmission types:

• normal transmissions [SWS_Dcm_00161],
• response-on-event transmissions [SWS_Dcm_00159], and
• periodic transmissions via ReadDataByPeriodicIdentifier [SWS_Dcm_00160].

As soon as Dcm_ComM_FullComModeEntered has been called, the DCM processes the internal functions DslInternal_ResponseOnOneDataByPeriodicId() and DslInternal_ResponseOnOneEvent() without restrictions [SWS_Dcm_00162]. In terms of timing, the DCM must wait for this call before transmission of a diagnostic response is initiated; the waiting time must not exceed P2ServerMax starting from the time of request receipt [SWS_Dcm_01142].

In the event of an error, if the passed NetworkId concerns a ComM channel that is not configured in the DCM (parameter DcmDslProtocolComMChannelRef), the function returns immediately and without further actions [SWS_Dcm_01326].

Usage and Semantics

The synchronous and reentrant callback function Dcm_CsmAsyncJobFinished is called by the Crypto Service Manager (CSM) as soon as asynchronous job processing is completed [SWS_Dcm_91076]. As an input parameter, it receives the result of the finished CSM job via result of type Csm_ResultType [SWS_Dcm_91076]. As a return value, the function always returns E_OK [SWS_Dcm_91076].

Configuration and Constraints

Integrators must configure the name of this function in the ECUC configuration of the CSM as a callback for asynchronous jobs [SWS_Dcm_91076]. For the DCM, only a single such callback is available; according to the specification, identification of the finished job takes place by evaluating the job parameter [SWS_Dcm_91076]. However, since the C function signature only passes result, the DCM is likely to determine the associated job internally via the transaction state of the ongoing authentication. Question Q-04ad1d5fb514f467 (open)

The interface is only available if the parameter DcmDspAuthenticationConnection is set in the configuration (not equal to null) [SWS_Dcm_91076]. Specific error handlings or DET messages are not specified for this call, since the return value is unalterably E_OK [SWS_Dcm_91076].

The synchronous and reentrant callback function Dcm_KeyMAsyncCertificateVerifyFinished is called by module KeyM after completion of an asynchronous certificate verification [SWS_Dcm_91077]. It informs the DCM about the completion as well as the result of the verification process and always returns E_OK as return value [SWS_Dcm_91077].

Parameters and Operation

• CertID: Identifier of the certificate whose verification has been completed. Based on this identifier, the DCM determines which verification job was completed [SWS_Dcm_91077].
• Result: Return value and status of the asynchronous verification job from the KeyM [SWS_Dcm_91077].

Configuration and Constraints

Integrators must configure this function name in the ECUC configuration of the KeyM as a callback for asynchronous jobs [SWS_Dcm_91077]. Since only a single callback is available for this notification, the DCM relies on resolving the respective certificate via the parameter CertID [SWS_Dcm_91077].

The interface is available exclusively if the configuration parameter DcmDspAuthenticationConnection is configured in the path Dcm/DcmDsp/DcmDspAuthentication (!= null) [SWS_Dcm_91077]. Special error codes or DET messages are not specified for this call [SWS_Dcm_91077].

The callout function Dcm_ReadMemory ([SWS_Dcm_00539]), declared in Dcm_Externals.h, serves the DCM for reading server memory data based on start address (MemoryAddress) and byte size (MemorySize). The function is required for the UDS services ReadMemoryByAddress (0x23) ([SWS_Dcm_00495]), ReadDataByIdentifier (0x22) for dynamic DIDs in the address range 0xF200 to 0xF3FF ([SWS_Dcm_00653]), RequestUpload, and TransferData ([SWS_Dcm_00539]). If the parameter MemoryIdentifier is not used, it must be set to 0 ([SWS_Dcm_00539]).

The interface is asynchronous and non-reentrant ([SWS_Dcm_00539]). The call status is passed via OpStatus with the values DCM_INITIAL, DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK. As long as the read operation is in progress, the function returns DCM_READ_PENDING ([SWS_Dcm_00985]). If the call returns DCM_READ_FORCE_RCRRP, the DCM immediately initiates transmission of an RCR-RP message (NRC 0x78) and pauses further calls until transmission confirmation ([SWS_Dcm_00839]). After confirmation of the RCR-RP, the DCM calls the function from Dcm_MainFunction again with OpStatus = DCM_FORCE_RCRRP_OK ([SWS_Dcm_00840]).

In case of success, the read data is written to buffer MemoryData and DCM_READ_OK is returned ([SWS_Dcm_00539], [SWS_Dcm_00985]). If the operation fails, the function returns DCM_READ_FAILED and sets ErrorCode. The DCM then sends a negative response with the corresponding NRC value ([SWS_Dcm_00644]).

The callout function Dcm_WriteMemory declared in Dcm_Externals.h is called asynchronously and non-reentrantly by the DCM to write memory data based on start address and byte size [SWS_Dcm_00540]. It serves to implement the UDS services WriteMemoryByAddress (0x3D), RequestDownload, and TransferData [SWS_Dcm_00540]. Upon receiving WriteMemoryByAddress, the DCM calls the callout only after verifying the request [SWS_Dcm_00491].

OpStatus is passed to control the sequence (possible values: DCM_INITIAL, DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK) [SWS_Dcm_00540]. The parameters MemoryAddress and MemorySize determine the target memory area, while MemoryData points to the diagnostic buffer of the DCM [SWS_Dcm_00540]. If MemoryIdentifier or MemoryAddress are not used (for example with compressed data), they must be set to 0 [SWS_Dcm_00540].

The return value Dcm_ReturnWriteMemoryType [SWS_Dcm_00986] defines further processing in the DCM:

• DCM_WRITE_OK: The write operation was successful [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_PENDING: The operation is not yet completed and requires subsequent calls [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_FORCE_RCRRP: The DCM immediately initiates transmission of a response pending (NRC 0x78) and suspends further calls until transmission confirmation [SWS_Dcm_00837]. Thereafter, the recall from Dcm_MainFunction is performed with DCM_FORCE_RCRRP_OK [SWS_Dcm_00838].
• DCM_WRITE_FAILED: In the event of an error, the DCM transmits a negative response with the NRC value passed via output parameter ErrorCode [SWS_Dcm_00540], [SWS_Dcm_00643].

The callout function Dcm_SetProgConditions enables the integrator to persistently save relevant information before transitioning to the bootloader or performing a reset as a result of an ECUReset request [SWS_Dcm_00543]. The relevant context data is passed via a pointer to structure Dcm_ProgConditionsType, which bundles, among other things, connection and tester source addresses, service and sub-function IDs, as well as control flags such as ReprogramingRequest and ResponseRequired [SWS_Dcm_00988]. Upon receipt of a UDS service 0x10 with sub-function 0x02, the DCM sets these flags and calls the interface [SWS_Dcm_01182].

The call is asynchronous and non-reentrant (Non Reentrant) [SWS_Dcm_00543]. The states DCM_INITIAL, DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK are controlled via parameter OpStatus [SWS_Dcm_00543]. If execution is ongoing and the function returns DCM_E_PENDING, the DCM calls the interface again in the next main function cycle to complete the setting [SWS_Dcm_00543], [SWS_Dcm_01184]. By means of DCM_E_FORCE_RCRRP, the transmission of a response pending reply (NRC 0x78) can be forced [SWS_Dcm_00543]. Depending on the configuration, the call by the DCM takes place only after successful transmission of NRC 0x78 [SWS_Dcm_00535].

If the conditions were set without errors and the callout returns E_OK, the DCM initiates the mode switch of ModeDeclarationGroupPrototype DcmEcuReset to EXECUTE [SWS_Dcm_00719], [SWS_Dcm_01163], [SWS_Dcm_01180]. If, on the other hand, the state cannot be saved and the function responds with E_NOT_OK, the reset as well as the bootloader jump are omitted, the mode switch is prevented, and the DCM sends the negative response NRC 0x22 (Conditions not correct) [SWS_Dcm_00715], [SWS_Dcm_01181].

The callout function Dcm_GetProgConditions with service ID 0x62 is called during initialization of the DCM to determine whether a pending diagnostic response to service $50 or $51 must be sent [SWS_Dcm_00544]. The declaration of the interface is provided via header file Dcm_Externals.h [SWS_Dcm_00544].

Usage and Parameters

Function execution is synchronous, with no regular input or input/output parameters being passed [SWS_Dcm_00544]:

• Output parameter: Via pointer ProgConditions of type Dcm_ProgConditionsType*, the callout returns the conditions under which the previous jump from the bootloader was requested [SWS_Dcm_00544]. The relevant context parameters are stored in data type Dcm_ProgConditionsType [SWS_Dcm_00544].
• Return value: The function returns a status value of type Dcm_EcuStartModeType to the caller [SWS_Dcm_00544].

Concurrency and Error Handling

The function is classified as non-reentrant (Non Reentrant) and must therefore not be executed concurrently [SWS_Dcm_00544]. No specific DET or DEM error codes are defined for this callout in the interface specification [SWS_Dcm_00544].

The callout function Dcm_ProcessRequestAddFile is called by the DCM to initiate the service RequestFileTransfer with the operating mode 0x01 (AddFile) ([SWS_Dcm_91078]). It is available via Dcm_Externals.h, has the service ID 0x72, and is specified as non-reentrant (Non Reentrant) and asynchronous ([SWS_Dcm_91078]).

Control of the asynchronous call sequence takes place via the parameter OpStatus:

• DCM_INITIAL: All input parameters are valid. These include file path and name (filePathAndName with filePathAndNameLength), the byte dataFormatIdentifier (high nibble for compression, low nibble for encryption), and the uncompressed and compressed file size (fileSizeUncompressed, fileSizeCompressed) ([SWS_Dcm_91078]).
• DCM_PENDING, DCM_CANCEL, and DCM_FORCE_RCRRP_OK: In these subsequent calls, all input parameters are set to 0x00 ([SWS_Dcm_91078]).

As return values, the function returns E_OK upon successful execution, DCM_E_PENDING upon ongoing processing, or DCM_E_FORCE_RCRRP if the application requests sending a preliminary response (NRC 0x78) ([SWS_Dcm_91078], [SWS_Dcm_91086]). In case of success, maxNumberOfBlockLength defines the maximum allowed block length of future TransferData messages without SID and block counter ([SWS_Dcm_91078]).

In the event of an error, the function returns E_NOT_OK. In this case, a negative response code (NRC) must be passed via the parameter ErrorCode, which the DCM sends to the client in a negative diagnostic response ([SWS_Dcm_91078]). If configuration DcmRequestFileTransferUsePort is enabled, this functionality is alternatively provided as port operation ProcessRequestAddFile of interface RequestFileTransfer ([SWS_Dcm_91086]).

Usage and invocation semantics

The callout function Dcm_ProcessRequestDeleteFile is called by the DCM to initiate the deletion of a file (modeOfOperation = 0x02) on the server within the scope of the diagnostic service RequestFileTransfer [SWS_Dcm_91079]. The function is declared in Dcm_Externals.h and operates asynchronously and non-reentrant (Non Reentrant) [SWS_Dcm_91079].

Passing and evaluation take place based on parameter OpStatus:

• DCM_INITIAL: Indicates the start of the operation. Here, all input parameters are valid; filePathAndName passes the storage location and name of the file to be deleted, the byte length of which is specified via filePathAndNameLength [SWS_Dcm_91079].
• DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK: During continued processing or cancellation, all input parameters are set to 0x00 [SWS_Dcm_91079].

As return values, the function returns E_OK upon successful execution, DCM_E_PENDING if execution is still ongoing and requires further calls, or DCM_E_FORCE_RCRRP if the application requests sending an interim message with NRC 0x78 (Response Pending) [SWS_Dcm_91079], analogous to the service RequestFileTransfer [SWS_Dcm_91086].

Error handling

If processing fails, the function returns E_NOT_OK. In this case, a negative response code must be provided via the output parameter ErrorCode, which the DCM transmits to the tester as a negative response (NRC) [SWS_Dcm_91079].

The callout function Dcm_ProcessRequestReplaceFile is called by the DCM to initiate a diagnostic process for RequestFileTransfer with the operating mode 0x03 (ReplaceFile) [SWS_Dcm_91080]. The function is defined as non-reentrant (Non Reentrant) and asynchronous and is provided via the header Dcm_Externals.h [SWS_Dcm_91080].

Control of the asynchronous processing sequence takes place via parameter OpStatus:

• During the initial call with DCM_INITIAL, the DCM passes all input parameters validly, including path and file name (filePathAndName with length specification filePathAndNameLength), the identifier for compression and encryption (dataFormatIdentifier), and the uncompressed and compressed file size (fileSizeUncompressed, fileSizeCompressed) [SWS_Dcm_91080].
• For subsequent calls or a cancellation (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK), all in-parameters are set to 0x00 [SWS_Dcm_91080].
• In case of success, the function returns the maximum payload length for subsequent TransferData requests (without SID and block sequence counter) to the DCM via the out-parameter maxNumberOfBlockLength [SWS_Dcm_91080].

The intended return values are E_OK upon successful execution, DCM_E_PENDING upon still ongoing processing, and DCM_E_FORCE_RCRRP to request a response-pending notification (NRC 0x78) [SWS_Dcm_91080], [SWS_Dcm_91086]. If execution fails, the function returns E_NOT_OK and assigns the corresponding negative diagnostic response code (NRC) to the parameter ErrorCode, which the DCM transmits to the tester [SWS_Dcm_91080].

The callout function Dcm_ProcessRequestReadFile is called by the DCM to start a file transfer process (Service RequestFileTransfer) with the operating mode ReadFile (modeOfOperation 0x04) [SWS_Dcm_91081]. The function is declared in the header Dcm_Externals.h, operates asynchronously, and is non-reentrant (Non Reentrant) [SWS_Dcm_91081].

The call is made via the status parameter OpStatus: During the initial call DCM_INITIAL, all input parameters are valid, whereas in subsequent calls with DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK they are set to 0x00 [SWS_Dcm_91081]. The application receives path and file name via filePathAndName (length in filePathAndNameLength), the format for compression and encryption via dataFormatIdentifier, and the file sizes via fileSizeUncompressed and fileSizeCompressed [SWS_Dcm_91081]. As an output parameter, the application must populate maxNumberOfBlockLength with the maximum byte count for subsequent TransferData responses (without SID and block sequence counter) [SWS_Dcm_91081].

As return values of Std_ReturnType, E_OK is defined upon successful execution, DCM_E_PENDING upon still ongoing asynchronous processing, or DCM_E_FORCE_RCRRP to request a \"Response Pending\" response (NRC 0x78) [SWS_Dcm_91081]. If the operation fails, it returns E_NOT_OK; in this case, the DCM transmits a negative response with the NRC value set in the output parameter ErrorCode to the tester [SWS_Dcm_91081]. The interaction corresponds to the general processing of the service RequestFileTransfer, as configured analogously for other file operations such as ProcessRequestAddFile [SWS_Dcm_91086].

use

The callout function Dcm_ProcessRequestReadDir is declared via header file Dcm_Externals.h and called by the DCM to asynchronously start the service RequestFileTransfer with the operating mode 0x05 (ReadDir) [SWS_Dcm_91082]. The processing progress is controlled via the passing parameter OpStatus [SWS_Dcm_91082]. Upon the initial call with DCM_INITIAL, the DCM passes the path or name via filePathAndName together with the byte length filePathAndNameLength [SWS_Dcm_91082]. In subsequent calls or upon cancellation (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK), all input parameters are set to 0x00 [SWS_Dcm_91082].

As output values, the application must provide the size of the directory data via dirInfoLength and the maximum allowed block size for subsequent transfers via maxNumberOfBlockLength [SWS_Dcm_91082]. In addition to E_OK upon successful execution, the function can return DCM_E_PENDING if the operation is still ongoing, or DCM_E_FORCE_RCRRP to cause the sending of an interim response (NRC 0x78) [SWS_Dcm_91082].

Error handling

If an error occurs, the function must return E_NOT_OK. In this case, the DCM reads the parameter ErrorCode and transmits its value as a negative response code (NRC) to the tester [SWS_Dcm_91082]. Specific DET or DEM messages are not provided for the interface; error checks of the passed path are therefore likely to be entirely the responsibility of the application-specific implementation. Question Q-278dbc3db7b4363b (open)

Concurrency and Interaction

The function is specified as non-reentrant (Non Reentrant) and therefore must not be called concurrently for multiple diagnostic requests [SWS_Dcm_91082]. It is part of the interface group of the service RequestFileTransfer, the integration of which can be influenced via configuration parameters [SWS_Dcm_91086].

Usage and Call Context

The callout function Dcm_WriteFile is called by the DCM when data is received via the UDS service TransferData (0x36) and a download process previously started via RequestFileTransfer with the modes 0x01 (AddFile) or 0x03 (ReplaceFile) is active [SWS_Dcm_01444]. The interface is available via Dcm_Externals.h [SWS_Dcm_91083].

Parameter population depends on the progress status OpStatus [SWS_Dcm_91083]:

• DCM_INITIAL: All input parameters are valid. The pointer Data points to the payload to be written, and DataLength indicates its byte length. The value of DataLength does not exceed the maximum block length previously negotiated for Dcm_ProcessRequestFileTransfer (NumberOfBlockLength).
• DCM_PENDING, DCM_CANCEL, and DCM_FORCE_RCRRP_OK: All input parameters are set to 0x00.

Asynchronous Semantics and Return Values

The function operates asynchronously and is non-reentrant (Non Reentrant) [SWS_Dcm_91083]. It returns the following status values:

• E_OK: The write operation was completed successfully.
• DCM_E_PENDING: Processing is not yet completed and requires further calls.
• DCM_E_FORCE_RCRRP: The application requests sending a wait response (Response Pending, NRC 0x78).
• E_NOT_OK: The operation failed.

Error handling

If Dcm_WriteFile returns the value E_NOT_OK, the DCM module sends a negative UDS response whose NRC corresponds to the value provided via the output parameter ErrorCode [SWS_Dcm_91083].

The callout function Dcm_ReadFileOrDir is called by the DCM module when, within the scope of an ongoing file or directory upload (previously started via UDS service RequestFileTransfer with mode 0x04 for ReadFile or 0x05 for ReadDir), a format-compliant request for the UDS service TransferData (0x36) is received [SWS_Dcm_01445]. The function serves to provide the data to be sent to the client as a response [SWS_Dcm_91085]. The interface declaration is available via the header Dcm_Externals.h [SWS_Dcm_91085].

Execution occurs asynchronously and is specified as non-reentrant (Non Reentrant) [SWS_Dcm_91085]. The interaction and parameter population depend on the passed operating status:

• Operating status (OpStatus): Upon the initial call with DCM_INITIAL, all input parameters are valid. For subsequent or cancellation calls with DCM_PENDING, DCM_CANCEL, or DCM_FORCE_RCRRP_OK, all input parameters are set to 0x00 [SWS_Dcm_91085].
• Buffer and block length: The parameter DataLength passes the maximum allowed block length on the input side (corresponding to the value maxNumberOfBlockLength reported to the client) and returns on the output side the byte length actually provided in Data, which must not exceed the input value [SWS_Dcm_91085]. Interpretation: Although Data is formally declared as an in-parameter in the interface, it is likely used to pass the payload to be read. Question Q-53de8a0bdbc4a2b4 (open)
• Return values: The operation returns E_OK upon successful data provision, DCM_E_PENDING upon not yet completed processing, or DCM_E_FORCE_RCRRP if the application wants to force the sending of an interim message (Response Pending, NRC 0x78) [SWS_Dcm_91085].

If processing in the application fails, E_NOT_OK is returned. In this error case, the DCM module transmits a negative UDS response (NRC) to the client whose error code corresponds to the value set in output parameter ErrorCode [SWS_Dcm_91085].

The function Dcm_MainFunction serves to process the central tasks of the main loop of the Diagnostic Communication Manager ([SWS_Dcm_00053]). It has the signature void Dcm_MainFunction(void) and provides no return values. Since it is provided via the header SchM_Dcm.h, its invocation likely occurs cyclically in the context of a basic software scheduler task. Question Q-e083a72aae447ab5 (open)

An essential task is the control and cross-cycle continuation of asynchronous processes:

• If an operation with Dcm_OpStatusType returns the return value DCM_E_PENDING, the DCM invokes the operation again with OpStatus = DCM_PENDING upon every call of Dcm_MainFunction as long as this status persists ([SWS_Dcm_00530]).
• If Dem_ClearDTC() returns the status DEM_PENDING, the function is called again in the next cycle of Dcm_MainFunction; the DCM sends NRC 78 (ResponsePending) if necessary ([SWS_Dcm_00703]).
• Calls of Dem_SetDTCFilter() with parameter FilterForFault-DetectionCounter set must imperatively take place in the context of Dcm_MainFunction ([SWS_Dcm_00519]).
• After confirmation of an RCR-RP transmission, the DCM calls operations such as Dcm_WriteMemory or Dcm_ReadMemory from Dcm_MainFunction again with OpStatus = DCM_FORCE_RCRRP_OK ([SWS_Dcm_00529], [SWS_Dcm_00838], [SWS_Dcm_00840]).
• If the value DCM_E_PENDING is reported for Xxx_GetSecurityAttemptCounter, the call is interrupted and resumed in the next cycle ([SWS_Dcm_01351]); if the configured timeout is exceeded, the DCM aborts the pending operation with OpStatus = DCM_CANCEL ([SWS_Dcm_01352]).

The function Xxx_GetSeed (provided via Dcm_Externals.h) serves the asynchronous provision of a seed value by the application for the DCM module [SWS_Dcm_01151]. It is called as soon as a UDS request of the service SecurityAccess (0x27) with the subfunction type "requestSeed" is received and the requested security level is not yet active [SWS_Dcm_00862], [SWS_Dcm_00324].

Call Context and Parameters

The interface is defined as non-reentrant (Non Reentrant) and operates asynchronously [SWS_Dcm_01151]:

• SecurityAccessDataRecord: Pointer to additional input data for the seed calculation; the minimum size is one byte according to DcmDspSecurityADRSize [SWS_Dcm_01151].
• OpStatus: Indicates the current status of the asynchronous operation [SWS_Dcm_01151].
• Seed: Output pointer via which the application provides the calculated seed [SWS_Dcm_01151].
• ErrorCode: Output parameter for returning a negative error code (NRC) [SWS_Dcm_01151].

Return Values and Error Handling

• E_OK: The seed was successfully determined and provided [SWS_Dcm_01151].
• DCM_E_PENDING: The calculation is not yet completed; subsequent calculations or calls are necessary for completion [SWS_Dcm_01151].
• E_NOT_OK: The request failed. In this case, the DCM module sends a negative UDS response with the NRC value passed in the parameter ErrorCode [SWS_Dcm_01151], [SWS_Dcm_00659].

Integration Notes

Depending on the configuration of DcmDspSecurityUsePort, the connection is established as a C function in USE_ASYNCH_FNC (referenced via DcmDspSecurityGetSeedFnc) [SWS_Dcm_00862] or as an Rte operation in USE_ASYNCH_CLIENT_SERVER [SWS_Dcm_00324]. If no additional access data needs to be passed, the alternative function signature without the parameter SecurityAccessDataRecord is used [SWS_Dcm_91003].

The function Xxx_GetSeed serves as an asynchronous interface of the module DCM to the application in order to provide a seed value in the context of the UDS service SecurityAccess (0x27) for a request of type "requestSeed" [SWS_Dcm_91003], [SWS_Dcm_00862]. The call is performed by the DCM DSP submodule provided that the security level is not yet active and the configuration specifies USE_ASYNCH_CLIENT_SERVER or USE_ASYNCH_FNC [SWS_Dcm_00324], [SWS_Dcm_00862].

The interface is implemented as asynchronous and non-reentrant (Non Reentrant) [SWS_Dcm_91003]. Control of the processing progress is performed via the input parameter OpStatus (type Dcm_OpStatusType) [SWS_Dcm_91003]. Defined return values are E_OK upon successful provision, E_NOT_OK in the event of an error, and DCM_E_PENDING if seed generation is still ongoing and further calls are required [SWS_Dcm_91003]. The generated value is passed via the pointer Seed (inout/out buffer) [SWS_Dcm_91003].

If the operation fails and Xxx_GetSeed returns E_NOT_OK, the DCM module must send a negative response (NRC) with the error code that was set via output parameter ErrorCode (Dcm_NegativeResponseCodeType) [SWS_Dcm_91003], [SWS_Dcm_00659]. The service is declared via header Dcm_Externals.h [SWS_Dcm_91003].

The function Xxx_CompareKey is called asynchronously and non-reentrantly by the Diagnostic Communication Manager ([SWS_Dcm_91004]) to compare a received key against the internal logic of the application within the scope of the UDS service SecurityAccess (0x27, subfunction sendKey) ([SWS_Dcm_00863]). It is used when the access status is not yet active, the seed request was successful, and the configuration parameter DcmDspSecurityUsePort is set to USE_ASYNCH_CLIENT_SERVER ([SWS_Dcm_00324]) or, according to [SWS_Dcm_00863], the function interface was configured via USE_ASYNCH_FNC/DcmDspSecurityCompareKeyFnc. The interface is declared in Dcm_Externals.h ([SWS_Dcm_91004]).

The passed arguments comprise the pointer to the key to be checked Key, the current operation status OpStatus (of type Dcm_OpStatusType), and the pointer ErrorCode for the negative response code to be output in case of an error ([SWS_Dcm_91004]). The following return values are specified:

• E_OK: Key verification successful ([SWS_Dcm_91004]).
• DCM_E_PENDING: Verification not yet completed; further calls by the DCM module are required for completion ([SWS_Dcm_91004]).
• E_NOT_OK: Processing not successful. The DCM then sends a negative UDS response with the NRC set in ErrorCode without changing the internal security level or incrementing the attempt counter (AttemptCounter) ([SWS_Dcm_01150]).
• DCM_E_COMPARE_KEY_FAILED: Key does not match ([SWS_Dcm_91004]).

If the key comparison fails (DCM_E_COMPARE_KEY_FAILED) and DcmDspSecurityNumAttDelay is configured, the AttemptCounter is incremented ([SWS_Dcm_01397]). If the counter is below the limit, the DCM sends NRC 0x35 (InvalidKey) ([SWS_Dcm_00660]). If the number of failed attempts reaches or exceeds the configured limit DcmDspSecurityNumAttDelay, the DCM starts the SecurityDelayTimer with duration DcmDspSecurityDelayTime and sends NRC 0x36 (exceededNumberOfAttempts) ([SWS_Dcm_01349]). In both cases, the security level remains unchanged.

During the initialization of the DCM, the asynchronous and non-reentrant function [SWS_Dcm_01152] reads the current failed attempt counter for a configured security level from the application. The call is made for each entry in DcmDspSecurityRow for which the configuration parameter DcmDspSecurityAttemptCounterEnabled is set to TRUE [SWS_Dcm_01154].

Flow control is managed via the parameter OpStatus with the values DCM_INITIAL, DCM_PENDING, or DCM_CANCEL [SWS_Dcm_01152]. If the function returns DCM_E_PENDING, the DCM interrupts the call chain and resumes it in the subsequent cycle of Dcm_MainFunction() [SWS_Dcm_01351]. If the timeout DcmDspSecurityMaxAttemptCounterReadoutTime configured after the first cycle is exceeded, the DCM aborts the still pending process with DCM_CANCEL [SWS_Dcm_01352].

In case of success, the interface returns E_OK and passes the counter value via the output parameter AttemptCounter [SWS_Dcm_01152]. If the call returns E_NOT_OK, the DCM automatically sets the counter to the value configured for this security level DcmDspSecurityNumAttDelay [SWS_Dcm_01156].

As long as not all counter values have been definitively determined or aborted, the DCM rejects any request for SecurityAccess (0x27) to request a seed with the negative response code conditionsNotCorrect (0x22) [SWS_Dcm_01354]. After completion of the query chain, the DCM checks the counter values: If at least one counter reaches or exceeds the threshold value DcmDspSecurityNumAttDelay, the DCM starts the SecurityDelayTimer with the higher value of DcmDspSecurityDelayTimeOnBoot and DcmDspSecurityDelayTime [SWS_Dcm_01355].

The function Xxx_SetSecurityAttemptCounter serves to set the attempt counter for a specific security level in the application ([SWS_Dcm_01153]). It is provided via the header Dcm_Externals.h.

Call and Semantics

Execution is asynchronous and specified as non-reentrant (Non Reentrant) ([SWS_Dcm_01153]). The call controls the flow via the parameter OpStatus with the values DCM_INITIAL, DCM_PENDING, or DCM_CANCEL. The new counter value is passed via the input parameter AttemptCounter (uint8).

Return Values and Error Handling

Std_ReturnType is used as the return type ([SWS_Dcm_01153]):

• E_OK: The request was completed successfully.
• E_NOT_OK: The execution was not successful.
• DCM_E_PENDING: Processing is not yet finished; further calls are required for completion.

If an ongoing asynchronous operation is cancelled, the DCM passes the status DCM_CANCEL ([SWS_Dcm_01153]).

Interaction and Boundary Conditions

The DCM module calls Xxx_SetSecurityAttemptCounter as soon as it has changed the attempt counter in order to notify the application of the update ([SWS_Dcm_01155]). This requires that the configuration parameter DcmDspSecurityAttemptCounterEnabled for the associated DcmDspSecurityRow is configured to TRUE ([SWS_Dcm_01155]). Since the interface is non-reentrant, the application must prevent concurrent execution for the same instance ([SWS_Dcm_01153]).

The synchronous function Xxx_ReadData requests the current data value of a DID or PID from the application if the configuration parameter DcmDspDataUsePort is set to USE_DATA_SYNCH_CLIENT_SERVER [SWS_Dcm_00793]. The interface is provided via the header Dcm_Externals.h and has the service ID 0x34 [SWS_Dcm_00793]. The called application copies the requested payload directly into the passed buffer Data [SWS_Dcm_00793].

Regarding the return value, it is defined that the call returns E_OK without exception [SWS_Dcm_00793]. Specific error codes, negative responses, or DET/DEM messages are not specified for this signature. Interpretation: A failure of the data provision is presumably not intended at this interface level, since, unlike the asynchronous variant [SWS_Dcm_91005], neither a parameter ErrorCode for negative response codes (NRC) nor return values such as E_NOT_OK or DCM_E_PENDING exist. Question Q-adcf0171ecfd37c4 (open)

Regarding concurrency and constraints, the function is specified as non-reentrant (Non Reentrant) and operates fully synchronously [SWS_Dcm_00793]. Interaction with diagnostic requests occurs in several scenarios:

• Upon receiving an OBD service $01 request with non-availability PIDs, the DCM calls the respectively configured Xxx_ReadData functions for all data of the PID to capture the response values [SWS_Dcm_00408].
• For a UDS request of service 0x22 (ReadDataByIdentifier) with non-availability identifiers, the DCM calls the functions for all data of the OBDDataIdentifier [SWS_Dcm_01380] as well as the OBDInfoTypeDataIdentifier [SWS_Dcm_01389].
• If, however, asynchronous behavior is required, the separate signatures with OpStatus according to [SWS_Dcm_91006] or [SWS_Dcm_91005] take effect.

The function Xxx_ReadData is used to query data values of a DID or PID asynchronously from the application, provided the parameter DcmDspDataUsePort is configured to USE_DATA_ASYNCH_CLIENT_SERVER ([SWS_Dcm_91006]). It is declared via the header file Dcm_Externals.h ([SWS_Dcm_91006]).

Upon invocation, the parameter OpStatus (type Dcm_OpStatusType) controls the progress of the ongoing operation, while via pointer Data (type uint8*) the output buffer into which the requested data is to be copied is passed ([SWS_Dcm_91006]). Defined return values are E_OK upon successful completion and DCM_E_PENDING if processing is still ongoing and requires further calls for completion ([SWS_Dcm_91006]).

The DCM module integrates this function into the following diagnostic sequences:

• Upon receiving an OBD Service $01, the DCM reads the current PID values (except availability PIDs) via the configured Xxx_ReadData functions ([SWS_Dcm_00408]).
• For UDS Service 0x22 (ReadDataByIdentifier), the DCM calls the function for OBDDataIdentifier ([SWS_Dcm_01380]) and OBDInfoTypeDataIdentifier ([SWS_Dcm_01389]).

Regarding execution, the function is specified as non-reentrant (Non Reentrant) ([SWS_Dcm_91006]). In contrast to the synchronous interface ([SWS_Dcm_00793]) or the asynchronous variant with an additional ErrorCode parameter ([SWS_Dcm_91005]), this function variant does not provide for a direct return of a negative response code.

The function Xxx_ReadData asynchronously requests the data value of a DID or PID from the application, provided configuration parameter DcmDspDataUsePort is set to USE_DATA_ASYNCH_CLIENT_SERVER [SWS_Dcm_91005]. The function declaration is provided via interface file Dcm_Externals.h [SWS_Dcm_91005].

The interface has the following invocation and operational characteristics:

• Semantics and parameters: Input parameter OpStatus controls the progress of the ongoing operation [SWS_Dcm_91005]. Upon successful completion, the requested payload data is copied into output buffer Data and E_OK is returned [SWS_Dcm_91005]. If the application requires further processing time, it signals DCM_E_PENDING, whereupon follow-up operations are required [SWS_Dcm_91005].
• Error handling: If the operation fails and returns E_NOT_OK, the DCM module evaluates output parameter ErrorCode and transmits a negative diagnostic response with this NRC code [SWS_Dcm_91005].
• Concurrency: The function is defined as non-reentrant (Non Reentrant) [SWS_Dcm_91005]. Interpretation: Repeated invocations during pending processing are likely executed sequentially within the cycle of the DCM main processing. Question Q-541226d5f242f7c2 (open)
• Interaction: The DCM module calls the function for requests of OBD Service $01 for non-availability PIDs [SWS_Dcm_00408] as well as for UDS Service ReadDataByIdentifier (0x22) for OBDDataIdentifier [SWS_Dcm_01380] and OBDInfoTypeDataIdentifier [SWS_Dcm_01389]. Compared to synchronous variant [SWS_Dcm_00793] or asynchronous interfaces without an NRC parameter [SWS_Dcm_91006], this signature enables a specific negative error transmission.

use

The function Xxx_WriteData is called by the Diagnostic Communication Manager (DCM) to request the application to write a DID data value (Data Identifier) ([SWS_Dcm_00794]). The declaration is provided via header Dcm_Externals.h. The call is synchronous under service ID 0x51 ([SWS_Dcm_00794]).

Parameters and return values:

• Data (in): Pointer to the buffer containing the payload data to be written ([SWS_Dcm_00794]).
• ErrorCode (out): Pointer to the variable into which the negative diagnostic code (NRC) is to be entered in case of a failure ([SWS_Dcm_00794]).
• Return value (Std_ReturnType): E_OK signals successful writing, E_NOT_OK indicates failure of the operation ([SWS_Dcm_00794]).

Error handling

If the function returns E_NOT_OK, the DCM module reads out parameter ErrorCode and sends a negative diagnostic response with this NRC code ([SWS_Dcm_00794]).

Concurrency and Limitations

The function is specified as non-reentrant (Non Reentrant) ([SWS_Dcm_00794]) and must not be executed concurrently.

Interaction

Since no length parameter exists, this variant is likely intended for DIDs with fixed data length. Question Q-ebc074ac1cb66aaa (open) For variable-length DIDs, AUTOSAR provides the synchronous signature with parameter DataLength ([SWS_Dcm_91007]). In addition, asynchronous variants with OpStatus and possible return of DCM_E_PENDING exist for prolonged operations, both with fixed data length ([SWS_Dcm_91008]) and with a variable length parameter ([SWS_Dcm_91009]).

The callback function Xxx_WriteData is used to request the application to write the data value of a Data Identifier (DID) [SWS_Dcm_91007]. The interface is declared via the header Dcm_Externals.h and has the service ID 0x52 [SWS_Dcm_91007]. The call is synchronous and is specified as non-reentrant (Non Reentrant), which is why no concurrent calls may occur for the same function [SWS_Dcm_91007].

As parameters, the function receives the buffer Data containing the payload to be written as well as DataLength with the length specification in bytes [SWS_Dcm_91007]. As return value, it returns the type Std_ReturnType with E_OK upon successful execution or E_NOT_OK in case of error [SWS_Dcm_91007]. If the operation fails and returns E_NOT_OK, the DCM module must send a negative response to the diagnostic tester; the Negative Response Code (NRC) corresponds to the value transmitted via the pointer parameter ErrorCode [SWS_Dcm_91007].

In the overall system, [SWS_Dcm_91007] represents the synchronous variant for DIDs with an explicit length specification. In addition, with [SWS_Dcm_00794] (service ID 0x51), a synchronous variant without the parameter DataLength exists. For longer write operations, the standard provides asynchronous interfaces: [SWS_Dcm_91008] (service ID 0x35) without length specification and [SWS_Dcm_91009] (service ID 0x3e) with DataLength. Both asynchronous functions are controlled via OpStatus and can return DCM_E_PENDING in addition to E_OK and E_NOT_OK [SWS_Dcm_91008] [SWS_Dcm_91009].

use

The function Xxx_WriteData requests the application to write the data value of a Data Identifier (DID) [SWS_Dcm_91008]. It is declared in the header file Dcm_Externals.h and has asynchronous execution semantics with the service ID 0x35 [SWS_Dcm_91008].

The parameters and return values are structured as follows [SWS_Dcm_91008]:

• Data (IN): Pointer to the buffer containing the data to be written.
• OpStatus (IN): Status of the current operation to control the asynchronous call sequence.
• ErrorCode (OUT): Pointer to the error code (NRC) that is set in case of error.
• Return value (Std_ReturnType): E_OK confirms the successful write operation, E_NOT_OK reports a failure, and DCM_E_PENDING indicates that the operation is still ongoing and requires further calls for completion.

Error Handling and Concurrency

If the call returns the value E_NOT_OK, the DCM module must transmit a negative response with the NRC value passed in the output parameter ErrorCode [SWS_Dcm_91008]. The function is specified as non-reentrant [SWS_Dcm_91008], so concurrent or overlapping calls for the same instance are not permitted.

Interaction and Variants

This interface according to [SWS_Dcm_91008] covers asynchronous write access without a separate length parameter. In this regard, AUTOSAR defines related variants in the DCM: a synchronous signature without length specification [SWS_Dcm_00794] as well as signatures with an additional parameter DataLength for synchronous [SWS_Dcm_91007] and asynchronous sequences [SWS_Dcm_91009].

Usage and Semantics

The function Xxx_WriteData requests the application to write the data value of a Data Identifier (DID) [SWS_Dcm_91009]. It is declared via the header file Dcm_Externals.h and has the service ID 0x3e [SWS_Dcm_91009]. Execution is asynchronous (Asynchronous), for which the following parameters are passed:

• Data (IN): Pointer to the buffer containing the payload to be written [SWS_Dcm_91009].
• DataLength (IN): Length of the data to be written in bytes [SWS_Dcm_91009].
• OpStatus (IN): Operation status (Dcm_OpStatusType) to control the asynchronous processing progress [SWS_Dcm_91009].
• ErrorCode (OUT): Pointer to receive a negative response code (NRC) in case of error [SWS_Dcm_91009].

Defined return values of type Std_ReturnType are E_OK (write request completed successfully), E_NOT_OK (request failed), and DCM_E_PENDING [SWS_Dcm_91009]. The status DCM_E_PENDING signals that the process is not yet finished and further subsequent calls are required for completion [SWS_Dcm_91009]. Interpretation: The DCM is likely to call the function again cyclically upon return of DCM_E_PENDING with continued OpStatus until a final result is available. Question Q-fdbd734dab052f5c (open)

Error Handling and Concurrency

If the function returns the value E_NOT_OK, the corresponding error code must be provided via the parameter ErrorCode; the DCM module then sends a negative response with this NRC value [SWS_Dcm_91009]. Specific DET or DEM messages are not defined in the payload for this interface. Regarding concurrency, the function is specified as non-reentrant (Non Reentrant) [SWS_Dcm_91009].

Interaction and Interface Variants

The signature [SWS_Dcm_91009] covers asynchronous write accesses with explicit length specification. Further variants of Xxx_WriteData exist in the DCM:

• Synchronous execution without length specification: [SWS_Dcm_00794] (service ID 0x51).
• Synchronous execution with length specification: [SWS_Dcm_91007] (service ID 0x52).
• Asynchronous execution without length specification: [SWS_Dcm_91008] (service ID 0x35).

use

With the function Xxx_ReadDataLength, the DCM module requests the application to determine and return the data length of a data element in bytes [SWS_Dcm_00796]. The interface is declared in the header Dcm_Externals.h and has the Service ID 0x36 [SWS_Dcm_00796]. The query is executed synchronously [SWS_Dcm_00796]. Via the output parameter DataLength of type uint16*, the application passes the byte length of the data to be read to the DCM [SWS_Dcm_00796]. Input or input/output parameters are not defined [SWS_Dcm_00796]. As return value, the function always returns E_OK of type Std_ReturnType [SWS_Dcm_00796].

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) [SWS_Dcm_00796]. Since the function operates synchronously and, according to the specification, always reports E_OK, no specific error codes or differing status returns are intended for this call [SWS_Dcm_00796].

Interaction

In addition to the synchronous function, an asynchronous variant of the same name exists with the Service ID 0x4c, which is likewise provided via Dcm_Externals.h [SWS_Dcm_91010]. While the synchronous version [SWS_Dcm_00796] does without an operation status, the asynchronous counterpart requires the input parameter OpStatus of type Dcm_OpStatusType [SWS_Dcm_91010]. In addition, the asynchronous interface can return the return value DCM_E_PENDING besides E_OK if the request is not yet completed and requires further calls for completion [SWS_Dcm_91010].

The function [SWS_Dcm_91010] (Service ID 0x4c) requests the application to determine the data length of a data element in bytes. It is declared in header Dcm_Externals.h and serves the Diagnostic Communication Manager (DCM) for flexible length querying of diagnostic data.

Usage and Semantics

Upon the call, the DCM module passes the current progress via the input parameter OpStatus of type Dcm_OpStatusType ([SWS_Dcm_91010]). The application writes the result of the query into the output parameter DataLength (type uint16*). If the data length is not immediately available, the function signals via the return value DCM_E_PENDING that processing is ongoing and further calls are required ([SWS_Dcm_91010]). As soon as the result is available, the application reports completion with E_OK.

Concurrency and Limitations

According to the specification, the function is classified as non-reentrant ([SWS_Dcm_91010]), which is why concurrent calls by the DCM must be excluded. Since the specification provides no specific error values other than DCM_E_PENDING, the DCM can probably always assume a validly set byte size upon return of E_OK. Question Q-e7ecd3a518e2cbcb (open)

Interaction

The asynchronous interface [SWS_Dcm_91010] differs from the related synchronous variant [SWS_Dcm_00796] (Service ID 0x36). The latter has no OpStatus parameter, is executed synchronously, and always returns the length immediately with E_OK. In contrast, [SWS_Dcm_91010] allows the application to spread time-intensive calculations asynchronously over multiple call cycles.

The synchronous callout function Xxx_ConditionCheckRead is provided via the header file Dcm_Externals.h and serves to query the application as to whether the conditions for reading out the diagnostic data are fulfilled [SWS_Dcm_00797].

The interface has no input parameters and signals the status of the check via the return value of type Std_ReturnType [SWS_Dcm_00797]:

• E_OK: The check was successful; the conditions for reading the data are fulfilled [SWS_Dcm_00797].
• E_NOT_OK: The check failed; reading out is not permitted [SWS_Dcm_00797].

If the function returns E_NOT_OK, the DCM module sends a negative response with the error code that the application passed via output parameter ErrorCode (type Dcm_NegativeResponseCodeType*) [SWS_Dcm_00797].

Regarding concurrency, the function is specified as non-reentrant (Non Reentrant) and is executed synchronously with service ID 0x49 [SWS_Dcm_00797]. The check should therefore presumably be evaluated application-side immediately without blocking wait times to avoid delaying the synchronous DCM caller. Question Q-ada29c78c29d961e (open)

In contrast to this synchronous operation, [SWS_Dcm_91011] defines an asynchronous variant under service ID 0x37. This additionally uses the input parameter OpStatus (type Dcm_OpStatusType) and, besides E_OK and E_NOT_OK, can also return DCM_E_PENDING if subsequent steps are required to finish the check [SWS_Dcm_91011].

Usage and Semantics

The function Xxx_ConditionCheckRead is provided via the header file Dcm_Externals.h and serves to query the application software whether the conditions for reading diagnostic data are fulfilled [SWS_Dcm_91011]. Execution takes place under Service ID 0x37 asynchronously [SWS_Dcm_91011]. The current status of the ongoing operation is passed via the input parameter OpStatus (type Dcm_OpStatusType) [SWS_Dcm_91011].

Return Values and Error Handling

As return value, the function provides a status of type Std_ReturnType [SWS_Dcm_91011]:

• E_OK: The request was successful and the read conditions are fulfilled [SWS_Dcm_91011].
• E_NOT_OK: The check failed [SWS_Dcm_91011]. In this case, the application must set a negative response code (NRC) of type Dcm_NegativeResponseCodeType via the output parameter ErrorCode; the DCM module then sends a negative response with this NRC [SWS_Dcm_91011].
• DCM_E_PENDING: The check is not yet completed, so further calls are required for completion [SWS_Dcm_91011].

Concurrency and Distinction

The interface is specified as non-reentrant (Non Reentrant) [SWS_Dcm_91011]. In contrast to this asynchronous variant, [SWS_Dcm_00797] defines a synchronous signature without the OpStatus parameter under Service ID 0x49, which exclusively returns E_OK or E_NOT_OK [SWS_Dcm_00797].

The asynchronous interface Xxx_GetScalingInformation is provided via the header Dcm_Externals.h and serves to request scaling information of a data element from the application [SWS_Dcm_91012]. The DCM module calls this function as soon as a diagnostic request for the UDS service ReadScalingByIdentifier is received, specifically for each datum configured for the requested DID [SWS_Dcm_00394].

Parameters and Return Values

The function defines the following parameters and semantics [SWS_Dcm_91012]:

• OpStatus (in): Passes the current status of the ongoing operation.
• ScalingInfo (out): Buffer for receiving the scaling information (scalingByte and scalingByteExtension).
• ErrorCode (out): Receives the negative response code if the operation fails.

As return values, E_OK upon successful completion, E_NOT_OK in case of an error, as well as DCM_E_PENDING if processing is not yet completed and requires further calls for completion are specified [SWS_Dcm_91012].

Error Handling and Concurrency

If the call returns E_NOT_OK, the DCM module must send a negative response whose NRC corresponds to the value provided via output parameter ErrorCode [SWS_Dcm_91012]. The function is specified as non-reentrant (Non Reentrant) [SWS_Dcm_91012]. Interpretation: Whether this asynchronous function with OpStatus or the alternatively specified synchronous variant without OpStatus [SWS_Dcm_00798] is called probably depends on the configuration of the respective DID. Question Q-c4054a798f17a52c (open)

The function Xxx_ReturnControlToECU is provided via the header Dcm_Externals.h and requests the application to return control of an input/output control (IOControl) to the ECU [SWS_Dcm_01285]. The call takes place synchronously and is specified as non-reentrant [SWS_Dcm_01285].

Parameters and Variants

The function signature depends on the configuration of the external control mask [SWS_Dcm_01285]:

• If DcmDspDidControlMask is set to DCM_CONTROLMASK_EXTERNAL and the mask size is up to four bytes (DcmDspDidControlMaskSize <= 0x04), the input parameter controlMask of type Dcm_ControlMask_{DID}Type is passed [SWS_Dcm_01285].
• If the mask size is five or more bytes (DcmDspDidControlMaskSize >= 0x05), the pointer controlMask2 of type uint8* is used instead [SWS_Dcm_01285].
• Via the output parameter ErrorCode (type Dcm_NegativeResponseCodeType*), the function transmits the specific negative response code (NRC) to the DCM in case of error [SWS_Dcm_01285].

Return Values and Error Handling

The function returns the status Std_ReturnType. Upon successful return of control, the application reports E_OK [SWS_Dcm_01285]. If the operation fails, the function must return E_NOT_OK; in this case, the DCM module sends a negative response with the NRC stored in ErrorCode to the diagnostic tester [SWS_Dcm_01285].

Interaction and Call Context

The DCM calls the configured function interface (parameter DcmDspDataReturnControlToEcuFnc) when DcmDspDataUsePort is configured to USE_DATA_SYNCH_FNC, USE_DATA_ASYNCH_FNC, or USE_DATA_ASYNCH_FNC_ERROR [SWS_Dcm_01435]. In addition to regular diagnostic actions, Xxx_ReturnControlToECU is called by the DCM in particular when an active IO control sequence must be aborted [SWS_Dcm_01435].

The synchronous function interface Xxx_ResetToDefault is provided via the header Dcm_Externals.h and serves to request an application to reset an I/O control (IOControl) to the default value [SWS_Dcm_01286].

Call Context and Parameters

The function has the Service ID 0x4d, operates synchronously, and is specified as non-reentrant [SWS_Dcm_01286]. Depending on the configured size of the external control mask, one of two alternative input parameters is passed:

• controlMask (type Dcm_ControlMask_{DID}Type) is used when DcmDspDataUsePort is configured to USE_DATA_SYNCH_FNC, DcmDspDidControlMask is set to DCM_CONTROLMASK_EXTERNAL, and DcmDspDidControlMaskSize is at most 0x04 [SWS_Dcm_01286].
• controlMask2 (type uint8*) is used when, under identical boundary conditions, DcmDspDidControlMaskSize is configured to be greater than or equal to 0x05 [SWS_Dcm_01286].

Return Values and Error Handling

If the reset could be performed successfully, the function returns E_OK [SWS_Dcm_01286]. If the operation fails, E_NOT_OK must be returned. In this case, the application sets the output parameter ErrorCode (type Dcm_NegativeResponseCodeType*) to the corresponding negative response code (NRC), which the DCM module transmits to the tester as negative feedback [SWS_Dcm_01286].

Interaction and Distinction

If the system is designed for asynchronous interface handling via USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR, the asynchronous variant with the additional parameter OpStatus and the Service ID 0x3c is used instead of this synchronous function [SWS_Dcm_01314].

The asynchronous function [SWS_Dcm_01314] requests the application to reset an input/output control (IOControl) to its default value. It is declared in Dcm_Externals.h and has the Service ID 0x3c. The progress of the operation is controlled via the parameter OpStatus. If processing is not yet completed, the function returns DCM_E_PENDING, whereas a successful completion is confirmed with E_OK.

Depending on the configuration and the mask size (DcmDspDidControlMaskSize up to 4 bytes or 5 bytes and above), controlMask or controlMask2 is additionally passed in the case of external masking [SWS_Dcm_01314]. If the reset fails, the function returns E_NOT_OK. In this case, a negative response code (NRC) must be passed via the output parameter ErrorCode, which the DCM module sends to the tester as a negative response [SWS_Dcm_01314].

The function is specified as non-reentrant (Non Reentrant) [SWS_Dcm_01314]. It is used when DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR. For synchronous interface configurations (USE_DATA_SYNCH_FNC), the synchronous variant without OpStatus exists alternatively [SWS_Dcm_01286].

use

The synchronous function Xxx_FreezeCurrentState (listed in the element catalog as Xxx_FreezeCurrentStateManager) serves to request an application to freeze the current state of an input or output control (IOControl) [SWS_Dcm_01290]. The function is available via the header file Dcm_Externals.h and has the service ID 0x4a AUTOSAR_SWS_DiagnosticCommunicationManager p. 279. (Interpretation: The prefix Xxx is likely to act as a placeholder for the respective application module.) Question Q-f8c864cda732acc2 (open)

The interface parameters depend on the configuration of the external control mask (DcmDspDidControlMask to DCM_CONTROLMASK_EXTERNAL) [SWS_Dcm_01290]:

• controlMask (input, type Dcm_ControlMask_{DID}Type): Is passed if the mask size DcmDspDidControlMaskSize is configured to be less than or equal to 4 bytes (<= 0x04).
• controlMask2 (input, type uint8*): Is used instead if the mask size comprises at least 5 bytes (=> 0x05).
• ErrorCode (output, type Dcm_NegativeResponseCodeType*): Pointer to receive a negative response code in case of errors.

Error Handling and Return Values

As Std_ReturnType, the function returns either E_OK upon successful execution or E_NOT_OK if the request was not successful [SWS_Dcm_01290]. If an error occurs and E_NOT_OK is returned, the application must enter a specific negative response code (NRC) in parameter ErrorCode; the DCM module then sends a negative diagnostic response with this NRC code AUTOSAR_SWS_DiagnosticCommunicationManager p. 279.

Concurrency and Limitations

The operation is specified as non-reentrant (Non Reentrant) [SWS_Dcm_01290]. Callers must ensure that calls for the same instance are processed synchronously and without concurrent overlap.

Usage and Call Context

The asynchronous function Xxx_FreezeCurrentState is called by the DCM module to request the application software to freeze the current state of an input/output control (IOControl) [SWS_Dcm_01315]. The declaration is provided via the header Dcm_Externals.h [SWS_Dcm_01315].

Parameters and Control Masks

The call occurs with the following parameters [SWS_Dcm_01315]:

• OpStatus: Transmits the current status of the asynchronous operation (Dcm_OpStatusType).
• controlMask or controlMask2: If the control mask is configured externally (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL) and the asynchronous function interface is used, the DCM passes the parameter controlMask (of type Dcm_ControlMask_{DID}Type) for up to 4 bytes and the pointer controlMask2 (uint8*) for 5 bytes or more, depending on DcmDspDidControlMaskSize.
• ErrorCode: Pointer to Dcm_NegativeResponseCodeType for returning an error code.

Return Values and Error Handling

The function returns a status of type Std_ReturnType [SWS_Dcm_01315]:

• E_OK: Freezing the state was successfully completed.
• DCM_E_PENDING: The request is still in progress and requires subsequent feeds.
• E_NOT_OK: The operation has failed. In this case, the DCM sends a negative diagnostic response with the NRC value set via ErrorCode.

Concurrency

The interface is defined as non-reentrant (Non Reentrant) and therefore requires synchronized processing per control instance [SWS_Dcm_01315].

The synchronous function Xxx_ShortTermAdjustment requests the application to temporarily adjust a specific I/O signal [SWS_Dcm_00802]. It is provided via the header Dcm_Externals.h and has the Service ID 0x50 [SWS_Dcm_00802].

Via the pointer ControlStateInfo, the function receives the control state information from the parameter ControlOptionRecord of the diagnostic request InputOutputControlByIdentifier [SWS_Dcm_00802]. If an external control mask is configured (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL), either controlMask (up to 4 bytes) of type Dcm_ControlMask_{DID}Type or controlMask2 (from 5 bytes) as uint8* is additionally passed depending on DcmDspDidControlMaskSize [SWS_Dcm_00802].

As return value, the operation returns Std_ReturnType [SWS_Dcm_00802]:

• E_OK: The adjustment of the I/O signal was executed successfully [SWS_Dcm_00802].
• E_NOT_OK: The adjustment failed [SWS_Dcm_00802]. In this case, the application must set a specific negative response code (Dcm_NegativeResponseCodeType) via the output parameter ErrorCode, which the DCM module returns to the tester in the negative diagnostic response [SWS_Dcm_00802].

The function is non-reentrant (Non Reentrant) and is called synchronously [SWS_Dcm_00802]. This synchronous variant is used if the data element is configured for synchronous function calls (DcmDspDataUsePort == USE_DATA_SYNCH_FNC) [SWS_Dcm_00802]. For asynchronously configured ports (USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR), on the other hand, the asynchronous variant with Service ID 0x55 and an extended parameter set including OpStatus and DataLength exists [SWS_Dcm_01316].

Usage and Call Context

The function [SWS_Dcm_01316] is called by the Diagnostic Communication Manager (DCM) and provided via Dcm_Externals.h. It asynchronously requests the application to adjust an IO signal within the scope of the diagnostic service InputOutputControlByIdentifier. The control data is passed via the pointer ControlStateInfo (from the parameter ControlOptionRecord), supplemented by the byte length DataLength. The flow is controlled via OpStatus: As long as the adjustment is ongoing, the application returns DCM_E_PENDING; after successful completion, it reports E_OK.

Variants and Mask Parameters

If the control mask is configured externally (DCM_CONTROLMASK_EXTERNAL), additional parameters are passed [SWS_Dcm_01316]:

• If the mask size is less than or equal to 4 bytes, controlMask of type Dcm_ControlMask_{DID}Type is passed.
• If the mask size is at least 5 bytes, controlMask2 is passed as a pointer to uint8 instead.

Error Handling and Concurrency

If the signal control fails, the function returns E_NOT_OK and sets the negative response code (NRC) via the pointer ErrorCode, which the DCM transmits in the negative response [SWS_Dcm_01316]. The function is specified as non-reentrant.

Interaction and Distinction

The interface is used when the DID data port is configured to USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR and the data type to UINT8_DYN [SWS_Dcm_01316]. It differs from the synchronous variant [SWS_Dcm_00802], which uses neither OpStatus nor DataLength and is intended for synchronous ports with static data types.

The function Xxx_IsDidAvailable serves for the asynchronous check of whether a requested Diagnostic Identifier (DID) is available within a defined DID range [SWS_Dcm_00803]. It is provided via the header Dcm_Externals.h and has the Service ID 0x53 [SWS_Dcm_00803].

Usage and Parameters

The call occurs with the following parameters [SWS_Dcm_00803]:

• DID (In): The identifier value of the DID to be queried [SWS_Dcm_00803].
• OpStatus (In): The current status of the operation for controlling the asynchronous flow [SWS_Dcm_00803].
• supported (Out): Indicates whether the DID is available in the range; DCM_DID_SUPPORTED denotes support, while DCM_DID_NOT_SUPPORTED indicates non-support [SWS_Dcm_00803].

Asynchronous Semantics and Return Values

Since the function is executed asynchronously, the determination may require multiple call steps [SWS_Dcm_00803]. The return value DCM_E_PENDING signals that the request is not yet completed and further calls are necessary for completion [SWS_Dcm_00803]. The return value E_OK is reported when the check is completed [SWS_Dcm_00803] (Interpretation: Presumably E_OK completes the query, whereupon the parameter supported contains the valid result). Question Q-22c62d306a7ac4f1 (open)

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) [SWS_Dcm_00803]. Parallel calls for the same or other DIDs within the same instance are therefore impermissible.

Usage and Parameter Interface

The function Xxx_ReadDidData (service ID 0x40) is available via Dcm_Externals.h and requests the data values of a data identifier (DID) from the application [SWS_Dcm_00804]. Passing and feedback take place via the following parameters:

• DID: Identifier of the requested Data Identifier [SWS_Dcm_00804].
• Data: Pointer to the buffer into which the read payload data must be copied [SWS_Dcm_00804].
• OpStatus: Progress or operation status of the current request [SWS_Dcm_00804].
• DataLength: Length of the data to be read [SWS_Dcm_00804].
• ErrorCode: Output parameter for receiving a negative response code (NRC) [SWS_Dcm_00804].

Asynchronous Semantics and Return Values

The function is defined as asynchronous (Asynchronous) and returns a status of type Std_ReturnType [SWS_Dcm_00804]:

• E_OK: Reading the data was successful [SWS_Dcm_00804].
• DCM_E_PENDING: The request is not yet completed; further calls are required for completion [SWS_Dcm_00804].
• E_NOT_OK: The operation was not successful [SWS_Dcm_00804].

Error Handling and Concurrency

If the application returns the return value E_NOT_OK for Xxx_ReadDidData, the DCM module sends a negative response with the NRC code set via the parameter ErrorCode to the diagnostic tester [SWS_Dcm_00804]. The function is specified as non-reentrant (Non Reentrant) [SWS_Dcm_00804]. Interpretation: Due to the asynchronous processing with DCM_E_PENDING, the call is likely to typically take place in the cyclic task context of the DCM. Question Q-5e41e9fb7dc261b9 (open)

The function Xxx_WriteDidData is called by the DCM module to request the application to write the data value of a DID [SWS_Dcm_00805]. The declaration is available via the header Dcm_Externals.h [SWS_Dcm_00805].

Call and Semantics

The call is asynchronous and is defined as non-reentrant (Non Reentrant) [SWS_Dcm_00805]. The following parameters are passed upon the call [SWS_Dcm_00805]:

• DID: Identifier of the data identifier to be written.
• Data: Pointer to the buffer with the data to be written.
• OpStatus: Status of the current operation.
• DataLength: Length of the data to be written in bytes.
• ErrorCode: Output parameter for the negative response code (NRC).

Return Values and Error Handling

As a return value, the function returns Std_ReturnType with the following meanings [SWS_Dcm_00805]:

• E_OK: The write request was executed successfully.
• DCM_E_PENDING: The operation is not yet completed; further calls are required for completion.
• E_NOT_OK: The operation was not successful. In this case, the DCM module sends a negative response with the NRC value passed in the output parameter ErrorCode.

The function Xxx_ReadDidRangeDataLength serves to request the application software to return the data length for a DID range [SWS_Dcm_01271]. It is part of the AUTOSAR module Dcm, has the service ID 0x5e, and is provided via the header file Dcm_Externals.h [SWS_Dcm_01271].

The call takes place with asynchronous semantics (Asynchronous) via the following interface parameters [SWS_Dcm_01271]:

• DID (IN, uint16): Identifies the specific data identifier (Data ID value) of the requested DID range [SWS_Dcm_01271].
• OpStatus (IN, Dcm_OpStatusType): Indicates the current processing status of the running operation [SWS_Dcm_01271].
• DataLength (OUT, uint16*): Pointer to the length of the data to be read or written [SWS_Dcm_01271].

The return value of type Std_ReturnType signals the result of the length query [SWS_Dcm_01271]:

• E_OK: The request was successful and the determined length is ready [SWS_Dcm_01271].
• E_NOT_OK: The request was not successful [SWS_Dcm_01271].
• DCM_E_PENDING: Execution is not yet completed and requires further subsequent calls for completion [SWS_Dcm_01271].

Regarding concurrency, the interface is specified as non-reentrant (Non Reentrant) [SWS_Dcm_01271].

The asynchronous interface Xxx_GetInfotypeValueData is called by the DCM module as soon as a diagnostic request for OBD Service $09 is received and the requested InfoType is not an availability InfoType [SWS_Dcm_00423]. To provide the data, the DCM calls all functions configured for this InfoType and aggregates the values as a response to Service $09 [SWS_Dcm_00423]. The declaration is available via Dcm_Externals.h [SWS_Dcm_91014].

The passing and returning of data takes place via defined buffer and status parameters [SWS_Dcm_91014]:

• OpStatus (in): Indicates the current progress status of the ongoing operation.
• DataValueBuffer (out): Buffer for receiving the specific InfoType payload.
• DataValueBufferSize (inout): Contains the maximum writable buffer size in bytes upon call and is populated by the called function with the actual number of written data bytes.

As an asynchronous function, it returns E_OK upon successful completion, E_NOT_OK upon errors, or DCM_E_PENDING if the operation is not yet complete and requires further calls for completion [SWS_Dcm_91014]. Since the function is specified as non-reentrant (Non Reentrant), concurrent calls must not occur for the same function [SWS_Dcm_91014].

The function Xxx_Start is declared via the header file Dcm_Externals.h and requests the application software to start the execution of a diagnostic routine [SWS_Dcm_01203]. The DCM module calls this function as soon as a UDS service request for RoutineControl (0x31) with the subfunction startRoutine has been received and successfully verified [SWS_Dcm_00400], or when a RoutineControl request with a non-availability OBDTestId is received [SWS_Dcm_01392].

The interface supports fixed as well as variable data formats and is operated asynchronously [SWS_Dcm_01203]:

• Input parameters: Fixed input signals dataIn_1 to dataIn_n or variable data via the byte array dataInVar as well as the operation status OpStatus [SWS_Dcm_01203].
• Output parameters: Fixed output signals dataOut_1 to dataOut_n or variable output data dataOutVar as well as the error code ErrorCode for negative response messages [SWS_Dcm_01203].
• Length parameter: In the case of variable data length, the input/output parameter currentDataLength carries the number of payload bytes in dataInVar or dataOutVar [SWS_Dcm_01203].
• Return values: E_OK confirms the successful start, E_NOT_OK reports a failure, DCM_E_PENDING signals ongoing processing steps, and DCM_E_FORCE_RCRRP requests the premature sending of a pending response (NRC 0x78) [SWS_Dcm_01203].

Regarding concurrency, Xxx_Start is defined as non-reentrant (Non Reentrant) [SWS_Dcm_01203]. In asynchronous sequences with the return value DCM_E_PENDING, the DCM module calls the function cyclically again with progressed OpStatus until the operation is completed [SWS_Dcm_01203].

If the operation finishes successfully with E_OK, the DCM module returns a positive UDS response with the data provided via dataOut as routineStatusRecord [SWS_Dcm_00401]. If execution fails with E_NOT_OK, the DCM transmits a negative response with the NRC specified in parameter ErrorCode [SWS_Dcm_01203]. In the context of OBD routines, a return value other than E_OK leads to sending NRC 0x22 [SWS_Dcm_01394].

use

According to [SWS_Dcm_91016], the function Xxx_StartConfirmation bindingly indicates the transmission of a response to a preceding StartRoutine request. The interface is declared in the header file Dcm_Externals.h and has synchronous execution semantics ([SWS_Dcm_91016]). As the only input parameter, ConfirmationStatus of type Dcm_ConfirmationStatusType is passed, which describes the confirmation status of the routine transmission. Additional input and output parameters do not exist according to the specification ([SWS_Dcm_91016]).

Error Handling and Return Values

As a return value, the function returns a status value of type Std_ReturnType ([SWS_Dcm_91016]). Here, the value E_OK confirms the successful execution of the request, whereas E_NOT_OK signals unsuccessful processing. Specific error codes or explicit notifications to the Development Error Tracer (DET) or Diagnostic Event Manager (DEM) are not defined in the payload for this function.

Concurrency and Limitations

Regarding concurrency, Xxx_StartConfirmation is classified as non-reentrant (Non Reentrant) ([SWS_Dcm_91016]). This requires the caller to strictly avoid concurrent or overlapping executions. Interpretation: The function is likely called by the DCM to notify the application-side routine implementation about the completion of the transmission process. Question Q-be2dafd63bf2a9a5 (open)

use

The function [SWS_Dcm_01204] is called by the DCM to terminate the execution of a running diagnostic routine in the application. The call takes place within the scope of the UDS service RoutineControl (0x31) with the subfunction stopRoutine as soon as the required pre-checks have been completed successfully [SWS_Dcm_00402]. The interface has the service ID 0x5c and is declared via the header file Dcm_Externals.h [SWS_Dcm_01204].

Parameters and Return Values

Depending on the configuration of the routine, the DCM passes fixed or variable input data (dataIn_1 to dataIn_n or dataInVar) and buffer references for output data (dataOut_1 to dataOut_n or dataOutVar) [SWS_Dcm_01204], [SWS_Dcm_00402]. In case of variable data length, currentDataLength contains the number of bytes of the input or output data [SWS_Dcm_01204]. The following are defined as return values of Std_ReturnType:

• E_OK: Routine successfully terminated; the DCM transmits a positive UDS response with the generated output data as routineStatusRecord [SWS_Dcm_01204], [SWS_Dcm_00403].
• E_NOT_OK: Termination of the routine failed; the DCM sends a negative UDS response with the NRC stored in ErrorCode [SWS_Dcm_01204].
• DCM_E_PENDING: Operation is still in progress; the DCM calls the function again for completion [SWS_Dcm_01204].
• DCM_E_FORCE_RCRRP: The application requests the DCM to transmit a pending response (NRC 0x78) [SWS_Dcm_01204].

Concurrency and Limitations

The operation is specified as asynchronous and non-reentrant (Non Reentrant) [SWS_Dcm_01204]. If an error occurs during execution, the application must write the appropriate Dcm_NegativeResponseCodeType to parameter ErrorCode and return E_NOT_OK [SWS_Dcm_01204].

The synchronous function Xxx_StopConfirmation serves to indicate the transmission of a response to a previous StopRoutine request [SWS_Dcm_91017]. Upon the call, the system passes the concrete confirmation status of the routine stop via input parameter ConfirmationStatus of type Dcm_ConfirmationStatusType [SWS_Dcm_91017]. As a return value, the interface returns a value of type Std_ReturnType: Here, E_OK indicates that the request was processed successfully, while E_NOT_OK signals an unsuccessful request [SWS_Dcm_91017].

Regarding concurrency and calling conditions, the interface is specified as non-reentrant (Non Reentrant) and has Service ID 0x69 [SWS_Dcm_91017]. The declaration is provided via header file Dcm_Externals.h [SWS_Dcm_91017]. Interpretation: Due to the provision via Dcm_Externals.h and the customizable prefix Xxx_, the function is likely called by the DCM module and implemented by an application-specific software component or the responsible routine handler. Question Q-743e69ff8cf92321 (open)

Specific error codes or notifications to the development error management (DET) or Diagnostic Event Manager (DEM) are not designated in the requirements. The error handling behavior at this interface level is formally limited to returning the error value E_NOT_OK if processing could not be successfully completed [SWS_Dcm_91017].

The function [SWS_Dcm_91013] is called by the DCM module to query the result of a routine execution from the application. This takes place within the scope of the UDS service RoutineControl (0x31) with the subfunction requestRoutineResults as soon as all input-side checks have been passed successfully [SWS_Dcm_00404]. The interface is available via Dcm_Externals.h, operates asynchronously, and is specified as non-reentrant [SWS_Dcm_91013].

The DCM module controls the progress of the operation via the parameter OpStatus. The function accepts fixed input data (dataIn_1 to dataIn_n) or variable data (dataInVar) derived from routineControlOptionRecord [SWS_Dcm_00404]. The application passes the result data to the DCM via fixed output parameters (dataOut_1 to dataOut_n) or variable output buffers (dataOutVar and variableDataLength) [SWS_Dcm_91013].

If the query is completed successfully with E_OK, the DCM module consolidates the output data into a routineStatusRecord based on the configuration parameter DcmDspRequestRoutineResultsOut and transmits a positive response [SWS_Dcm_00405]. If the operation is still ongoing, the application can return DCM_E_PENDING for subsequent calls or DCM_E_FORCE_RCRRP to send a preliminary response (NRC 0x78) [SWS_Dcm_91013].

In the event of an error, the function returns E_NOT_OK and sets ErrorCode to the applicable NRC value, whereupon the DCM module transmits a corresponding negative response [SWS_Dcm_91013]. Since the function is non-reentrant, it must not be called concurrently for the same routine [SWS_Dcm_91013].

Usage and Semantics

The function Xxx_RequestResultsConfirmation serves to confirm a transmitted diagnostic response to a RequestRoutineResults request [SWS_Dcm_91018]. It is declared in header file Dcm_Externals.h and has Service ID 0x70 [SWS_Dcm_91018]. Via the input parameter ConfirmationStatus of type Dcm_ConfirmationStatusType, the implementation receives information about the status with which the transmission of the routine results was completed [SWS_Dcm_91018]. The call is executed synchronously and returns a Std_ReturnType, where E_OK indicates successful processing and E_NOT_OK signals failure [SWS_Dcm_91018].

Concurrency and Limitations

According to the specification, the function is classified as non-reentrant (Non Reentrant) [SWS_Dcm_91018]. Therefore, concurrent calls for the same instance must not occur. Interpretation: The call by the DCM module occurs sequentially in the context of the response confirmation, which is why the function should be executed without blocking operations. Question Q-935a06744e7b9af7 (open)

Error Handling and Interaction

Error handling is limited to the return value E_NOT_OK, as separate development errors (DET) or production errors (DEM) are not specified for this call [SWS_Dcm_91018]. Interpretation: The function serves as an application-specific confirmation endpoint (callback) for the DCM to synchronize the completion of the diagnostic request at user level after sending the routine results. Question Q-d3dd0142a30e1363 (open)

The function Xxx_RequestControl serves to execute a TID-specific control function and is typically used to implement OBD Service $08 ([SWS_Dcm_01338]). The DCM module calls the configured function synchronously as soon as an OBD Service $08 request is received whose Test ID (TID) does not represent an availability TID ([SWS_Dcm_00419]). The declaration of the interface is provided via the header file Dcm_Externals.h ([SWS_Dcm_01338]).

Parameters and Buffer Handling

• InBuffer: Pointer to the payload of the received OBD request. The byte count of this input data must exactly match the size configured in the DCM module ([SWS_Dcm_00419], [SWS_Dcm_01338]).
• OutBuffer: Pointer to the output buffer in which the called control function stores its results. The buffer size is fixed and is taken from the configuration of the DCM module ([SWS_Dcm_00419], [SWS_Dcm_01338]).

Return Values and Error Handling

The function returns Std_ReturnType as status value: The value E_OK indicates successful processing, whereas E_NOT_OK indicates an error condition ([SWS_Dcm_01338]). If Xxx_RequestControl returns a result other than E_OK, the DCM module responds with the negative response code NRC 0x22 (Conditions Not Correct) to the diagnostic tester ([SWS_Dcm_01192]).

Concurrency and Limitations

The function is specified as non-reentrant (Non Reentrant) and has the service ID 0x63 ([SWS_Dcm_01338]).

The callback function Xxx_StartProtocol is provided via the header Dcm_Externals.h and allows the application, upon the first request of a diagnostic protocol, to check current environmental conditions and to enable or reject further protocol processing [SWS_Dcm_01339].

Call Context and Parameters

The call is performed by the DSL submodule of the DCM synchronously and non-reentrantly for all configured functions [SWS_Dcm_00036], [SWS_Dcm_01339]. The following input parameters are passed to the function [SWS_Dcm_01339]:

• ProtocolType: Type of the diagnostic protocol to be started,
• TesterSourceAddress: Source address of the requesting tester,
• ConnectionId: Unique identifier of the connection.

Return Values and Error Handling

As a return value, the function returns Std_ReturnType with E_OK upon successful release, E_NOT_OK if the check was unsuccessful, or E_PROTOCOL_NOT_ALLOWED if the protocol is invalid [SWS_Dcm_01339]. If at least one configured Xxx_StartProtocol function does not return E_OK, the DCM aborts protocol start and responds with NRC 0x22 [SWS_Dcm_00674].

Initialization after Successful Release

Only after all configured Xxx_StartProtocol callbacks have returned E_OK does the DCM execute the further initialization steps:

• Loading of the standard timing parameters from the default session configuration [SWS_Dcm_00144],
• Activation of the service table [SWS_Dcm_00145],
• Resetting of the security status (Security State) [SWS_Dcm_00146],
• Resetting of the session status to the default diagnostic session as well as executing the mode switch via SchM_Switch_<bsnp>_DcmDiagnosticSessionControl to RTE_MODE_DcmDiagnosticSessionControl_DEFAULT_SESSION [SWS_Dcm_00147].

The synchronous callback function Xxx_StopProtocol informs the application about the termination of a diagnostic protocol ([SWS_Dcm_01340]). It is declared via the header file Dcm_Externals.h and is specified as non-reentrant (Non Reentrant) ([SWS_Dcm_01340]).

The invocation of all configured Xxx_StopProtocol functions (configured via the parameter DcmDslCallbackDCMRequestService) is triggered by the DSL submodule in the following preemption scenarios:

• An ongoing diagnostic request is preempted by a higher-priority request of another protocol ([SWS_Dcm_00459]).
• A request with lower or equal priority preempts a higher-priority protocol, provided the latter is in the Default Session and no active request is in the execution phase ([SWS_Dcm_00625]).

Upon invocation, the protocol type (ProtocolType), the tester source address (TesterSourceAddress), and the connection identifier (ConnectionId) are passed ([SWS_Dcm_01340]). As a return value, the function returns E_OK upon successful execution or E_NOT_OK ([SWS_Dcm_01340]). If the function does not return E_OK, the DCM responds with the negative response code NRC 0x22 ([SWS_Dcm_01190]).

The synchronous, non-reentrant function Xxx_Indication is declared via the header Dcm_Externals.h [SWS_Dcm_01341]. It indicates the impending execution of a diagnostic service to the application and allows it to reject the execution of the service request [SWS_Dcm_01341]. The call is made synchronously by the DSD submodule at all configured ServiceRequestIndication ports if the configuration containers DcmDsdServiceRequestManufacturerNotification [SWS_Dcm_00218] or DcmDsdServiceRequestSupplierNotification [SWS_Dcm_00516] are present.

The service ID (SID), the request data without SID (RequestData, DataSize), the addressing type (ReqType), the connection ID (ConnectionId), the protocol type (ProtocolType), and the source address of the tester (TesterSourceAddress) are passed as input parameters [SWS_Dcm_01341].

Via the return value of type Std_ReturnType, the application controls the response of the DSD submodule [SWS_Dcm_01341]:

• E_OK: The request was successful and is processed further normally [SWS_Dcm_01341].
• E_REQUEST_NOT_ACCEPTED: The request is not accepted. If at least one called indication function returns E_REQUEST_NOT_ACCEPTED, the DSD submodule suppresses any response to the tester [SWS_Dcm_00462], [SWS_Dcm_00517].
• E_NOT_OK: The request was not successful. In this case, the application writes a negative response code to the output parameter ErrorCode [SWS_Dcm_01341]. Provided that no call returns E_REQUEST_NOT_ACCEPTED, the DSD submodule sends a negative response with this NRC [SWS_Dcm_00463], [SWS_Dcm_00518].

If multiple functions return E_NOT_OK and no function returns E_REQUEST_NOT_ACCEPTED when multiple notifications are configured, the DSD submodule mandatorily uses the ErrorCode of the first function responding with E_NOT_OK for the negative response [SWS_Dcm_01321], [SWS_Dcm_01322].

The callback function Xxx_Confirmation serves to synchronously notify the application of the completion of a diagnostic transmission—either the successful transmission or a transmission error ([SWS_Dcm_01342]). The declaration is provided via the header Dcm_Externals.h ([SWS_Dcm_01342]).

When called by the DCM submodule DSD (Diagnostic Service Dispatcher), essential context data of the diagnostic order is passed ([SWS_Dcm_01342], [SWS_Dcm_00741]):

• SID: Identifier of the diagnostic service ([SWS_Dcm_01342]).
• ReqType: Addressing type (0 for physical, 1 for functional) ([SWS_Dcm_01342]).
• ConnectionId, ProtocolType, and TesterSourceAddress: Unique connection and protocol attributes as well as the source address of the tester ([SWS_Dcm_01342]).
• ConfirmationStatus: Status information about the success or error of the transmission ([SWS_Dcm_01342]).

The operation returns Std_ReturnType as return value (E_OK upon successful confirmation processing, otherwise E_NOT_OK) ([SWS_Dcm_01342]). The DSD calls the function on all ports that use the interface ServiceRequestNotification (configured via DcmDsdServiceRequestManufacturerNotification or DcmDsdServiceRequestSupplierNotification) ([SWS_Dcm_00741]).

Regarding the call sequence, Xxx_Confirmation is regularly executed directly after DspInternal_DcmConfirmation() ([SWS_Dcm_00742]). However, if the special case according to [SWS_Dcm_01172] applies, the DSD exclusively calls Xxx_Confirmation, while the internal call is omitted.

Since Xxx_Confirmation is specified as non-reentrant (Non Reentrant) and synchronous ([SWS_Dcm_01342]), the application-side implementation should presumably contain no blocking processes and trigger no reentrant callbacks into the DCM (interpretation). Question Q-58ce3e44dc61540b (open)

use

The synchronous callout function Xxx_ClearDTCCheckFnc is provided for the application via the header file Dcm_Externals.h [SWS_Dcm_01270]. It serves for manufacturer- and supplier-specific checking of conditions before clearing a requested group of diagnostic trouble codes (Group of DTC). The identifier GoDTC of type uint32, which specifies the DTC group to be cleared, is passed to it as an input parameter [SWS_Dcm_01270].

Error Handling and Return Values

The release of the clear request takes place via the return value of type Std_ReturnType in conjunction with the output parameter ErrorCode [SWS_Dcm_01270]:

• E_OK: The application permits clearing the requested trouble code group GoDTC [SWS_Dcm_01270].
• E_NOT_OK: The application prohibits clearing the group. In this error case, a negative response code must be set via the output parameter ErrorCode of type Dcm_NegativeResponseCodeType*. The DCM module then sends a negative response with the NRC value specified in ErrorCode [SWS_Dcm_01270].

Concurrency and Limitations

The function is provided with the service ID 0x5f, operates synchronously, and is defined as non-reentrant (Non Reentrant) [SWS_Dcm_01270]. The call context must therefore ensure that calls take place sequentially and without concurrent overlapping.

The callout function Xxx_ProcessRequestDownload ([SWS_Dcm_00754]) is called by the module Dcm to initiate a download process during processing of the UDS service RequestDownload. It is defined as asynchronous and non-reentrant and is provided via the header Dcm_Externals.h ([SWS_Dcm_00754]).

Usage and Parameters

The call takes place step by step via the parameter OpStatus with the values DCM_INITIAL, DCM_PENDING, or DCM_CANCEL ([SWS_Dcm_00754]). The compression and encryption methods (DataFormatIdentifier), the memory block (MemoryIdentifier), the start address (MemoryAddress), and the uncompressed memory size in bytes (MemorySize) are passed as input parameters ([SWS_Dcm_00754]). Prior to the call, the Dcm writes the maximum possible buffer size to the inout parameter BlockLength ([SWS_Dcm_01417]). The function adjusts this value to the maximum permissible block length for subsequent write operations ([SWS_Dcm_00754]).

Return Values and Interaction

The function returns E_OK upon successful execution, DCM_E_PENDING if processing is still ongoing, or E_NOT_OK in the event of an error ([SWS_Dcm_00754]):

• If the call returns E_OK and the negotiated value BlockLength is less than or equal to the supported buffer length of the current protocol connection, the Dcm sends a positive response with this value as maxNumberOfBlockLength ([SWS_Dcm_01419]).
• If the returned buffer length exceeds the supported buffer size of the protocol connection, the Dcm reports the DET error DCM_E_INTERFACE_BUFFER_OVERFLOW ([SWS_Dcm_01418]).
• Upon return of E_NOT_OK, the Dcm sends a negative UDS response (NRC) with the value set in the output parameter ErrorCode ([SWS_Dcm_00754], [SWS_Dcm_00757]).

The callout function Xxx_ProcessRequestTransferExit is called by the DCM module to terminate an ongoing download or upload process within the scope of the UDS service RequestTransferExit [SWS_Dcm_00755]. The declaration of the interface is provided via the header Dcm_Externals.h [SWS_Dcm_00755].

Usage and Semantics

The function is operated asynchronously and is defined as non-reentrant [SWS_Dcm_00755]. The call is made by passing the current execution status OpStatus (possible values: DCM_INITIAL, DCM_PENDING, or DCM_CANCEL) [SWS_Dcm_00755]. The following return values of type Std_ReturnType are specified:

• E_OK: The transfer was completed successfully [SWS_Dcm_00755].
• DCM_E_PENDING: The transfer termination is not yet completed and requires subsequent calls [SWS_Dcm_00755].
• E_NOT_OK: The termination failed or the response buffer is too small [SWS_Dcm_00755].

Error Handling and Interaction

If the operation Xxx_ProcessRequestTransferExit returns the error value E_NOT_OK, a negative response code must be passed via the output parameter ErrorCode. The DCM module then sends a negative UDS response (NRC) with this exact error code to the diagnostic tester [SWS_Dcm_00759]. In case of an abort call, the DCM module passes the status DCM_CANCEL to the function [SWS_Dcm_00755].