AUTOSAR_SWS_DiagnosticCommunicationManager

二月 14, 2026

Specification of Diagnostic Communication Manager

Introduction and functional overview

The Dcm SWS describes the functionality, the API, and the configuration of the AUTOSAR Basic Software module Dcm (Diagnostic Communication Manager). The Dcm module provides a common API for diagnostic services. The functionality of the Dcm module is used by external diagnostic tools during the development, manufacturing or service.

Figure 1.1: Overview of the communication between the external diagnostic tools and the onboard AUTOSAR Application

The Dcm module ensures diagnostic data flow and manages the diagnostic states, especially diagnostic sessions and security states. Furthermore, the Dcm module checks if the diagnostic service request is supported and if the service may be executed in the current session according to the diagnostic states.The Dcm module provides the OSI-Layers 5 to 7 of Table 1: Diagnostic protocols and OSI-Layer.

Table 1.1: Diagnostic protocols and OSI-Layers

At OSI-level 7, the Dcm module provides an extensive set of ISO14229-1 [1] services. In addition, the Dcm module provides mechanisms to support the OBD services $01 - $0A defined in documents [3, SAE J1979] and [2, ISO 15031-5]. With these services, Autosar OBD functionality is capable of meeting all light duty OBD regulations worldwide (California OBDII, EOBD, Japan OBD, and all others). At OSI-level 5, the Dcm module handles the network-independent sections of the following specifications:

ISO15765-3 [4]: Implementation of unified diagnostic services (UDS on CAN)

ISO15765-4 [5]: Requirements for emission-related systems, Chapter 5 "Session Layer"

In the AUTOSAR Architecture the Diagnostic Communication Manager is located in the Communication Services (Service Layer).

Figure 1.2: Position of the Dcm module in AUTOSAR Architecture

The Dcm module is network-independent. All network-specific functionality (the specifics of networks like CAN, LIN, FlexRay or MOST) is handled outside of the Dcm module. The PDU Router (PduR) module provides a network-independent interface to the Dcm module. The Dcm module receives a diagnostic message from the PduR module. The Dcm module processes and checks internally the diagnostic message. As part of processing the requested diagnostic service, the Dcm will interact with other BSW modules or with SW-Components (through the RTE) to obtain requested data or to execute requested commands. This processing is very service-specific. Typically, the Dcm will assemble the gathered information and send a message back through the PduR module.

Acronyms and Abbreviations

Typographical Conventions

This document uses the following typographical conventions:

see configuration parameter myConfigurationParameter: this is a reference to a configuration parameter which can be found in Chapter 10.

myFunction(): this is a function provided or required by the module as defined in Chapter 8

Constraints and assumptions

Limitations

The following limitations apply when using the Dcm module:

The Dcm module does not provide any diagnostic multi-channel capabilities. This means that parallel requests of a tester addressed to different independent functionalities cannot be processed by a single Dcm module. Furthermore, the concept currently implemented does not take more than one instance of a Dcm module residing in one ECU into account. As the legislator requires that emissionrelated service requests according to ISO 15031-5 [2] shall be processed prior to any enhanced diagnostic requests, the Dcm module provides a protocol switching mechanism based on protocol prioritization.

UDS Service AccessTimingParameter (0x83) is not supported by the ISO standards in CAN and LIN. Also it is not planned to support this service with FlexRay. Therefore no support for this service is planned.

Subfunction onComparisionOfValues of Service ResponseOnEvent is not supported in the current release.

Subfunction onTimerInterrupt of Service ResponseOnEvent is not supported in the current release.

UDS Service SecuredDataTransmission (0x84) is not supported in the current release.

The Dcm SWS does not cover any SAE J1939 related diagnostic requirements.

Due to DEM limitation, the diagnostic service $19 05 is limited to the OBD legislative freeze frame.

Management of IOControl service without InputOutputControlParameter in request and response is not supported.

The length of controlState parameter in IOControl request and response has to be of same size (due to the one configuration parameter DcmDspDataByteSize).

Same layout of a DID which is used in RDBI, WDBI or IOCBI services.

The user optional parameter DTCSettingControlOptionRecord in the ControlDTCSetting request is only supported if it corresponds to a groupOfAllDTCs (0xFFFFFF) value. In other cases it has to be managed in a vendor specific implementation.

Only the ControlDTCSetting sub-functions 0x01 and 0x02 are supported.

The handling of infrastructure errors reported by the RTE during DCM/DEM <- > SW-C interactions is missing from the SWS and might have to be taken into account by implementers if they need it.

The Dcm does not support DLT for ROE

The ROE ServiceToRespondTo does not support PageBuffering

ROE only supports sub-function listed in Table 2

DID range feature cannot be applied for services DynamicallyDefineDataIdentifier, ReadDataByPeriodicIdentifier and InputOutputControlById

AUTOSAR Dcm is not intended to be used in the bootloader

PeriodicTransmission is not possible on FlexRay, as ISO 14229-4 demands header information (address information (source and target address) and FPL (Frame Payload length)). This information can't be filled with the specified concept of IF interface.

The specification of the transformer for intra ecu communication between the Dcm module and the NvBlockSoftwareComponentType is not standardized in the current AUTOSAR release. For this scenario custom transformers implemented by a complex driver can be used. To elaborate on this the responsible stakeholder (usually the OEM) needs to specify the custom transformer from a behavioral point of view in a separate document (this might include definition of byte-ordering or alignment). If there is the necessity to define transformer specific attributes in the model this can be done using special data groups in UserDefinedTransformationDescription and UserDefinedTransformationISignalProps. For the configuration of this scenario, a DataPrototypeMapping shall exist for the affected SenderReceiverInterfaces of the Dcm module and the NvBlockSoftwareComponentType which refers to a DataTransformation in the role firstToSecondDataTransformation. This DataTransformation shall reference exactly one TransformationTechnology in the role transformerChain with the transformerClass attribute set to "serializer" and may compose a UserDefinedTransformationDescription in the role transformationDescription.

In certain situations the Dcm module is capable to process diagnostic requests in parallel. This possibility is explicitly limited of OBD in parallel to UDS protocol processing. No other protocol combination can be processed in parallel. Particularly the use case of parallel processing of two or more UDS protocol requests or WWH-OBD and UDS protocols is not supported.

For UDS service 0x29, the Dcm supports only the sub-functions for PKI. Authentication via challenge response is not supported.

For UDS service 0x29, secure diagnostic communication with Diffie-Hellmann key exchange is not supported.

For UDS service 0x29 the Dcm does not support NRC 'Certificate verification failed - Invalid Content'.

The Dcm supports only selected subset of functionality according to ISO 14229- 1:2020 [8]. Unless explicitly stated the Dcm follows the ISO 14229-1:2013 [1].

Autosar PduR architecture allows the use of streaming protocols. As diagnostic protocols do not use streaming protocols, the Dcm does not support it either and therefore the Dcm_StartOfReception with TpSduLength equal to zero is not supported.

The Dcm has a different order of NRCs for UDS service 0x36. The ISO14229-1 [1] defined NRC order for that service would require further APIs that would make the overall service processing more complicated. Details can be found in chapter 7.6.2.21.

Applicability to car domains

The Dcm module can be used for all car domains.

Applicability to emission-related environments (OBD)

This Dcm SWS is intended to fulfill the emission related requirements given by legislator. However, the supplier of the emission related system is responsible to fulfill the OBD requirements. Certain requirements cannot be fulfilled by the Dcm module by itself, but need to be considered at the level of the entire ECU or system. Example: During the integration of the Dcm module within the system, the timing requirements (50ms response time) must be fulfilled.

For WWH-OBD only the FunctionalGroupIdentifier 0x33 is currently supported.

Dependencies to other modules

The AUTOSAR Diagnostic Communication Manager (DCM) has interfaces and dependencies to the following Basic Software modules and SW-Cs:

Figure 5.1: Interaction of the Dcm with other modules

Diagnostic Event Manager (DEM): The DEM module provides function to retrieve all information related to fault memory such that the Dcm module is able to respond to tester requests by reading data from the fault memory.

Protocol Data Unit Router (PduR module): The PduR module provides functions to transmit and receive diagnostic data. Proper operation of the Dcm module presumes that the PduR interface supports all service primitives defined for the Service Access Point (SAP) between diagnostic application layer and underlying transport layer (see ISO14229-1 [1], chapter 5 Application layer services).

Communication Manager (ComM): The ComM module provides functions such that the Dcm module can indicate the states "active" and "inactive" for diagnostic communication. The Dcm module provides functionality to handle the communication requirements "Full-/ Silent-/ No-Communication". Additionally, the Dcm module provides the functionality to enable and disable Diagnostic Communication if requested by the ComM module.

SW-C and RTE: The Dcm module has the capability to analyze the received diagnostic request data stream and handles all functionalities related to diagnostic communication such as protocol handling and timing. Based on the analysis of the request data stream the Dcm module assembles the response data stream and delegates routines or IO-Control executions to SW-Cs .If any of the data elements or functional states cannot be provided by the Dcm module itself the Dcm requests data or functional states from SW-Cs via port-interfaces or from other BSW modules through direct function-calls.

BswM: The Dcm notifies the BswM that the application was updated if the initialization of the Dcm is the consequence of a jump from the bootloader . The Dcm also indicates to the BswM a communication mode change.

Crypto Service Manager (Csm): The crypto service module provides a wide range of cryptographic algorithms. The Csm is used for authentication calculation.

Key Manager (KeyM): The key manager module provides support for certificate handling and APIs to realize authenticated diagnostics via certificates.

Requirements Tracing

Functional specification

Security Events

[SWS_Dcm_01589]

[RS_Ids_00810]

If security event reporting has been enabled for the Dcm module ( DcmEnableSecurityEventReporting = true) the respective security events shall be reported to the IdsM via the interfaces defined in AUTOSAR_SWS_BSWGeneral.

Security events for Dcm

[SWS_Dcm_01590]

[RS_Ids_00810]

Error Classification

This section describes how the Dcm module has to treat the several error classes that may happen during the life cycle of the Dcm module.

Diagnostic-Communication-Errors are handled directly in the ISO-Protocols by NRCs.

[SWS_Dcm_00044]

[SRS_BSW_00369]

The error values shall be the unique for all error types. The Dcm shall use only the values given in this chapter.

Section "Error Handling" of the document "General Specification of Basic Software Modules" describes the error handling of the Basic Software in detail. Above all, it constitutes a classification scheme consisting of five error types which may occur in BSW modules.

Based on this foundation, the following section specifies particular errors arranged in the respective subsections below.

Development Errors

The errors and exceptions described in [SWS_Dcm_00040] shall be detectable by the Dcm module depending on its build version (development/production mode).

[SWS_Dcm_00040]

[SRS_BSW_00337]

Runtime Errors

The errors and exceptions described in [SWS_Dcm_01416] shall be detectable by the Dcm module depending on its build version (development/production mode).

[SWS_Dcm_01416]

[SRS_BSW_00452]

General design elements

Submodules within the Dcm module

To define the functionality of the Dcm module, The Dcm SWS models the Dcm module as consisting of the following submodules:

Diagnostic Session Layer (DSL) submodule: The DSL submodule ensures data flow concerning diagnostic requests and responses, supervises and guarantees diagnostic protocol timing and manages diagnostic states (especially diagnostic session and security).

Diagnostic Service Dispatcher (DSD) submodule: The DSD submodule processes a stream of diagnostic data. The submodule:

Receives a new diagnostic request over a network and forwards it to a data processor.

Transmits a diagnostic response over a network when triggered by the data processor (e.g. by the DSP submodule).

Diagnostic Service Processing (DSP) submodule: The DSP submodule handles the actual diagnostic service (respectively subservice) requests.

The next graphic gives an overview of the interfaces between the submodules DSP, DSD, and DSL within the Dcm module.

Figure 7.1: Possible interaction between the submodules in the DCM

Note:

The implementation of these submodules and the interfaces between them is not mandatory. They are introduced only to improve the readability of the specification.

Negative Response Code (NRC)

The standards defining the UDS Services and OBD Services define the negative response codes (NRCs). The Dcm SWS uses these NRCs in the interfaces between the Dcm and other BSW modules and the SW-Cs. These NRCs are defined in the data type Dcm_NegativeResponseCodeType.

[SWS_Dcm_01075]

[ ]

The order of the transmitted NRC shall be compliant with the one described in ISO14229-1 [1].

Non-volatile information

Several features of the Dcm require non-volatile information to be initialized. AUTOSAR does not describe how this information is accessed or if the information is already available when the Dcm is initialized. Therefore the access for the non-volatile information is implementation specific and has to be ensured during integration.

[SWS_Dcm_00870]

[ ]

The Dcm shall check if the NvM is read out correctly. If the nonvolatile information could not read out correct the Dcm shall start a default reaction. The default reaction is described in the chapter were the usage of the non-volatile data is described.

[SWS_Dcm_01048]

[ ]

If the Dcm cancels a service with NvM access, it shall call NvM_CancelJobs().

The service is cancelled either by reaching the maximum number of RCRRP NRCs or by protocol preemption.

Types

[SWS_Dcm_00969]

[ ]

The Dcm shall treat non-integer data types (e.g. uint8[n]) either like integer data types of the matching size or leave their contents uninterpreted in case DcmDspDataEndianness is configured to OPAQUE.

[SWS_Dcm_00970]

[ ]

The Dcm module shall interpret opaque data as uint8[n] and shall always map it to an n-bytes sized signal. For opaque data endianness, DcmDspDataEndianness has to be configured to OPAQUE.

[SWS_Dcm_00971]

[ ]

The Dcm shall extend the endianness conversion defined in [12], to signed data types.

In [12] (Chapter 2.4) the endianness conversion is defined for unsigned data types. The associated configurations can be found in the configuration DcmDspData.

Atomic types overview

Figure 7.2: Atomic types overview

Data array types overview

Figure 7.3: Data array types overview

Nested Data types overview

The data types used for DIDs and Diagnostic Routines may be defined in a nested way. A DID or Routine Argument may consist of several elements, e.g. an array where each array element is a structure, and that structure consists of several data elements typed by primitives, arrays, or further structures.

In the configuration this represented by a dedicated pattern:

the root data element defines a pool of nested elements (e.g. DcmDspDidSignalCompositePool in DcmDspDid)

the root data element has an anchor object (e.g. DcmDspDidSignal), this anchor object may represent primitive or array data, in this case there is no reference to a pool element defined (e.g. DcmDspDidSignalCompositeRef).

if the anchor object represents a structure, then it defines one or more references to pool elements (e.g. DcmDspDidSignalCompositeRef). This defines that the referenced pool elements build the content of that structure.

A pool element may itself be a nested definition. This allows for an arbitrary nesting of structured elements.

Figure 7.4: Nested data for DcmDspDid

[SWS_Dcm_01633]

[ ]

If a DcmDspDidSignal contains at least one DcmDspDidSignalCompositeRef, then that DcmDspDidSignal shall only define the following parameters:

DcmDspDidByteOffset

DcmDspDataByteSize

Specifically this means that DcmDspDidSignal shall not define any DcmDspDidDataRef, as this would give details about specific data type information of primitive or array data types. If the DcmDspDidSignal contains a DcmDspDidSignalCompositeRef then this DcmDspDidSignal is a nested data type.

[SWS_Dcm_01634]

[ ]

The nested data type occupies a consecutive number of bytes ( DcmDspDataByteSize) starting at the position DcmDspDidByteOffset.

[SWS_Dcm_01635]

[ ]

All of the data types that are defined in the scope of the nested data type shall be placed inside the area defined by DcmDspDataByteSize and DcmDspDidByteOffset.

[SWS_Dcm_01636]

[ ]

The DcmDspDidByteOffset values of nested data elements shall be given to the absolute starting position of the DID (NOT relative to the respective composite structure).

[SWS_Dcm_01637]

[ ]

Each DcmDspDidSignalCompositePool shall only be referenced up to once by a DcmDspDidSignalCompositeRef. Each DcmDspDidSignalCompositePool element is specifically defined to be at a dedicated position in the DID and can only occur once in the definition of the DcmDspDid.

[SWS_Dcm_01638]

[ ]

A DcmDspDidSignalCompositeRef shall only refer to DcmDspDidSignalCompositePool elements which are defined in the scope of the same DcmDspDid as the owner of the DcmDspDidSignalCompositeRef.

The specification above has been defined on the basis of the DcmDspDid. The same pattern for the definition of nested data types has been applied to further parts of the configuration. The following list gives the respective correspondence between the configuration items used above and the further configuration items used for the definition of nested data types.

[SWS_Dcm_01639]

[ ]

The nesting of data types does not only apply to DcmDspDid, but is also supported for the following definitions:

DcmDspDid corresponds to

DcmDspStartRoutineIn

DcmDspStartRoutineOut

DcmDspStopRoutineIn

DcmDspStopRoutineOut

DcmDspRequestRoutineResultsIn

DcmDspRequestRoutineResultsOut

DcmDspDidSignal corresponds to

DcmDspStartRoutineInSignal

DcmDspStartRoutineOutSignal

DcmDspStopRoutineInSignal

DcmDspStopRoutineOutSignal

DcmDspRequestRoutineResultsInSignal

DcmDspRequestRoutineResultsOutSignal

DcmDspDidSignalCompositePool corresponds to

DcmDspStartRoutineInSignalCompositePool

DcmDspStartRoutineOutSignalCompositePool

DcmDspStopRoutineInSignalCompositePool

DcmDspStopRoutineOutSignalCompositePool

DcmDspRequestRoutineResultsInSignalCompositePool

DcmDspRequestRoutineResultsOutSignalCompositePool

DcmDspDidSignalCompositeRef corresponds to

DcmDspStartRoutineInSignalCompositeSignalRef

DcmDspStartRoutineOutSignalCompositeSignalRef

DcmDspStopRoutineInSignalCompositeSignalRef

DcmDspStopRoutineOutSignalCompositeSignalRef

DcmDspRequestRoutineResultsInSignalCompositeSignalRef

DcmDspRequestRoutineResultsOutSignalCompositeSignalRef

The example nested data type in figure 7.5 is defined as A which consists of X and Y defined as primitive types.

Figure 7.5: Nested data type for DcmDspStartRoutineIn

A starts at position 2 of the DcmDspStartRoutineIn and has a size of 4 byte. The nested leaf elements X and Y are defined within the range of the structure A and do not overlap. In this example there is even a gap left between X and Y.

Figure 7.6: Example configuration of nested data for DcmDspStartRoutineIn

In figure 7.6 an example configuration is shown for a nested data type of figure 7.5.

The container DcmDspStartRoutineIn holds the definition of the root element DcmDspStartRoutineInSignal_Signal_A as well as the two pool elements DcmDspStartRoutineInSignalContainedPool_X and DcmDspStartRoutineInSignalContainedPool_Y.

The root element DcmDspStartRoutineInSignal_Signal_A defines its absolute start position as 2 (DcmDspRoutineSignalPos_Signal_A) and its size in byte as 4 (DcmDspRoutineParameterSize_Signal_A). The root element DcmDspStartRoutineInSignal_Signal_A also defines that there are two nested elements part of that root element using the references DcmDspStartRoutineInSignalContainedPool_X and DcmDspStartRoutineInSignalContainedPool_Y. These references point to pool elements defined in the scope of the same DcmDspStartRoutineIn.

The referenced pool elements define each their absolute position (DcmDspRoutineSignalPos_Signal_X) as well as their size (DcmDspRoutineParameterSize_Signal_X) and primitive type (DcmDspRoutineSignalType_Signal_X).

Data types constraints

Existence of size parameter

[SWS_Dcm_CONSTR_06002]

[ ]

DcmDspDataByteSize shall be present if DcmDspDataType is set to: UINT8_N, SINT8_N, UINT16_N, SINT16_N, UINT32_N, SINT32_N or UINT8_DYN.

Note:

DcmDspDataByteSize is not required for primitive datatypes

Restrictions on size parameter for 16 Bit arrays

[SWS_Dcm_CONSTR_06035]

[ ]

DcmDspDataByteSize shall be a multiple of 2 if the value is greater than 2 and DcmDspDataType is UINT16_N or SINT16_N.

Restrictions on size parameter for 32 Bit arrays

[SWS_Dcm_CONSTR_06036]

[ ]

DcmDspDataByteSize shall be a multiple of 4 if the value is greater than 4 and DcmDspDataType is UINT32_N or SINT32_N.

Define the usage of DcmDspRoutineParameterSize parameter

[SWS_Dcm_CONSTR_06008]

[ ]

DcmDspRoutineParameterSize is only required if DcmDspRoutineSignalType is set to SINT8_N, SINT16_N, SINT32_N, UINT8_N, UINT16_N, UINT32_N or VARIABLE_LENGTH.

Only last parameters in RID may have a variable length

[SWS_Dcm_CONSTR_06011]

[ ]

DcmDspRoutineSignalType with VARIABLE_LENGTH is only valid for the last signal.

Existence of size parameter

[SWS_Dcm_CONSTR_06012]

[ ]

DcmDspPidDataByteSize shall be present if DcmDspPidDataType is set to: UINT8_N, SINT8_N, UINT16_N, SINT16_N, UINT32_N or SINT32_N.

Note:

DcmDspPidDataByteSize is not required for primitive datatypes

Restrictions on size parameter for 16 Bit arrays

[SWS_Dcm_CONSTR_06040]

[ ]

DcmDspPidDataByteSize shall be a multiple of 2 if the value is greater than 2 and DcmDspPIDDataType is UINT16_N or SINT16_N.

Restrictions on size parameter for 32 Bit arrays

[SWS_Dcm_CONSTR_06041]

[ ]

DcmDspPidDataByteSize shall be a multiple of 4 if the value is greater than 4 and DcmDspPIDDataType is UINT32_N or SINT32_N.

UINT8 shall be used as (implementation) data type for bit lengths between 1 and 8.

Restrictions on datatype usage

[SWS_Dcm_CONSTR_06038]

[ ]

DcmDspDataType shall be UINT8_N, in case DcmDspDataUsePort is equal to USE_BLOCK_ID.

Usage of variable data length in case of S/R communication, NvRam access or ECU signal access

[SWS_Dcm_CONSTR_06026]

[ ]

In case DcmDspDataUsePort is set to {USE_DATA_SENDER_RECEIVER, USE_DATA_SENDER_RECEIVER_AS_SERVICE, USE_BLOCK_ID, USE_ECU_SIGNAL}, the usage of variable data length shall be not allowed.

[SWS_Dcm_CONSTR_06031]

[ ]

The DcmDspData.SHORT-NAME and DcmDspPidData.SHORT-NAME shall be distinct.

Note:

Variable data length is only possible with UINT8 arrays with DcmDspDataType set to UINT8_DYN.

Dcm_OpStatusType

For the operation using the Dcm_OpStatusType, the Dcm shall work as follow :

[SWS_Dcm_00527]

[ ]

At first call of an operation using the Dcm_OpStatusType, the Dcm call the operation with OpStatus = DCM_INITIAL.

[SWS_Dcm_00528]

[ ]

If the value DCM_E_FORCE_RCRRP is returned from an operation using Dcm_OpStatusType, the Dcm shall invoke the transmit request for RCR-RP (NRC 0x78 transmission) and the Dcm shall not realize further invocation of the operation till RCR-RP is transmitted.

[SWS_Dcm_00529]

[ ]

After transmit confirmation of a RCR-RP transmitted on the context of [SWS_Dcm_00528], the Dcm calls, from Dcm_MainFunction (due to call context), the operation again with OpStatus = DCM_FORCE_RCRRP_OK.

[SWS_Dcm_00530]

[ ]

If a DCM_E_PENDING value is returned from an operation using the Dcm_OpStatusType, the Dcm call the operation on each Dcm_MainFunction call with OpStatus = DCM_PENDING as long as DCM_E_PENDING is returned.

Dcm_Cemr_{DID}Type

For ease of use in SWC, the Dcm generates a symbolic name to access the CEMR bit according to Dcm_Cemr_{DID}Type (see [SWS_Dcm_91087]) for each data element used in a DID with IO control. The SWC can work only with the generated symbolic value of the bitfield text table to mask out a certain bit. This helps to avoid confusion, while the first RID bit on the network controls the first parameter of the DID but that Bit is the most significant Bit in the MSB. The symbolic name also helps if the size of the RID is changing. In that case the bitmask changes as well, but the symbolic value is always updated.

Diagnostic Session Layer (DSL)

Introduction

[SWS_Dcm_00030]

[RS_Diag_04003]

[RS_Diag_04015]

All functional areas of the DSL submodule shall be in conformance with the specifications ISO14229-1 [1], ISO14229-2 [13] and the networkindependent part of ISO15765-3 [4].

There is no network-dependent functional area in the DSL submodule. Within the configuration, some parameters can be set dependent on the network.

Use cases

The DSL submodule provides the following functionalities:

Session handling (as required by ISO14229-1 [1] and ISO 15765-3 [4])

Application layer timing handling (as required by ISO14229-1 [1] and ISO 15765-3 [4])

Specific response behavior (as required by ISO14229-1 [1] and ISO 15765-3 [4])

Authentication state handling per diagnostic connection (as required by ISO 14229-1:2018)

Provide authentication state per connection

Manage authentication state transitions

Interaction with other modules

The DSL has the following interaction with other modules:

PduR module

PduR module provides data of incoming diagnostic requests.

The DSL submodule triggers output of diagnostic responses.

DSD submodule

The DSL submodule informs the DSD submodule about incoming requests and provides the data.

The DSD submodule triggers output of diagnostic responses.

SW-Cs / DSP submodule. The DSL submodule provides access to security and session state.

ComM module

The DSL submodule guarantees the communication behavior required by the ComM module

Functional description

Overview

The DSL submodule provides the following functionality:

Request Handling

Forward requests from the PduR module to the DSD submodule.

Concurrent TesterPresent (”keep alive logic”).

Response Handling

Forward responses from the DSD submodule to the PduR module.

Guarantee response timing to tester.

Support of periodic transmission.

Support of ResponseOnEvent (ROE) transmission.

Support of segmented response.

Support of ResponsePending response triggered by the application.

Security Level Handling

Manage security level.

Session State Handling

Manage session state.

Keep track of active non-default sessions.

Allows modifying timings.

Diagnostic Protocol Handling

Handling of different diagnostic protocols.

Manage resources.

Communication Mode Handling

Handling of communication requirements (Full- / Silent- / No Communication).

Indicating of active / inactive diagnostic.

Enabling / disabling all kinds of diagnostic transmissions.

Forward requests from the PduR module to the DSD submodule

The PduR module indicates the Dcm module whenever a reception of new diagnostic request content is started on a DcmDslProtocolRxPduId, which is assigned to the Dcm module. This is done by calling Dcm_StartOfReception, which inform the Dcm module of the data size to be received and provides the data of the first frame or single frame, and allows the Dcm to reject the reception if the data size overflows its buffer size, or if the requested service is not available. The further call to Dcm_CopyRxData request the Dcm module to copy the data from the provided buffer to the Dcm buffer. If the reception of a diagnostic request is finished (when Dcm_StartOfReception succeeded) the PduR module will call Dcm_TpRxIndication to give a receive indication to the Dcm module. The Dcm shall be able to use generic connections, where the addressing information is provided to Dcm by Dcm_StartOfReception via the MetaData of the DcmRxPdu. This addressing information must be stored and used for the response and for detection of requests from the same tester. see section 7.4.4.5 Generic Connection Handling for further details.

[SWS_Dcm_00111]

[RS_Diag_04249]

The DSL submodule shall forward received data to the DSD submodule only after a call of Dcm_TpRxIndication with parameter Result = E_OK (see [SWS_Dcm_00093]).

[SWS_Dcm_00241]

[ ]

As soon as a request message is received (after a call of Dcm_- TpRxIndication with parameter Result = E_OK (see [SWS_Dcm_00093]) and until a call to Dcm_TpTxConfirmation (see [SWS_Dcm_00351]) for the associated TxDcmPduId), the DSL submodule shall block the corresponding DcmPduId. During the processing of this request, no other request of the same DcmDslConnection (e.g. an enhanced session can be ended by a OBD session) can be received, until the corresponding response message is sent and the DcmPduId is released again (except for Concurrent TesterPresent requests).

More descriptions of the APIs (prototype, input/output parameter) can be found in the interface description of PduR module [14].

It is allowed to have different DcmPduIds for different diagnostic communication applications. For example:

OBD DcmDslProtocolRxPduId: for reception of OBD requests,

OBD DcmTxPduId: for transmission of OBD responses,

UDS phys DcmDslProtocolRxPduId: for reception of UDS physically addressed requests,

UDS func DcmDslProtocolRxPduId: for reception of UDS functionally addressed requests,

UDS DcmTxPduId: for transmission of UDS responses.

Address type (physical/functional addressing) is configured per DcmDslProtocolRxPduId. A configuration per DcmDslProtocolRxPduId is possible because there will always be different DcmDslProtocolRxPduId values for functional and physical receptions, independent of the addressing format of the Transport Layer (extended addressing, normal addressing).

Dcm_StartOfReception

[SWS_Dcm_00444]

[ ]

If the requested size is large than the buffer available in the DCM, the function Dcm_StartOfReception shall return BUFREQ_E_OVFL (see [SWS_Dcm_00094]).

[SWS_Dcm_00788]

[ ]

When processing a diagnostic request and in case DcmDslDiagRespOnSecondDeclinedRequest is set to TRUE, the Dcm module shall return BUFREQ_OK on Dcm_StartOfReception received on new request using a different DcmDslConnection.

[SWS_Dcm_00789]

[ ]

In case [SWS_Dcm_00788], the Dcm respond with a NRC 0x21.

[SWS_Dcm_00790]

[ ]

When processing a diagnostic request, the Dcm module shall reject (Dcm_StartOfReception shall return BUFREQ_E_NOT_OK) any new request using a different DcmDslConnection in case DcmDslDiagRespOnSecondDeclinedRequest is set to FALSE until the current diagnostic request processing is over.

[SWS_Dcm_00557]

[RS_Diag_04249]

When processing a diagnostic request, the Dcm module shall reject (Dcm_StartOfReception shall return BUFREQ_E_NOT_OK) any new diagnostic request with the same DcmDslConnection until the current diagnostic request processing is over. Concurrent TesterPresent requests will be accepted with a BUFREQ_OK, but not further processed, as the running diagnostic request already resets the session timeout timer (S3Server).

[SWS_Dcm_01145]

[RS_Diag_04249]

If the current session is a non-default session and a Concurrent TesterPresent received on a different DcmDslConnection, this request will be accepted with a BUFREQ_OK, but not further processed. E.g. it is not resetting the session timeout timer (S3Server)

[SWS_Dcm_01146]

[ ]

In case of [SWS_Dcm_01145] with reception on a higher priority protocol, this will not lead to protocol preemption.

[SWS_Dcm_00642]

[RS_Diag_04147]

When the API Dcm_StartOfReception is invoked with TpSduLength equal to 0, the value BUFREQ_E_NOT_OK shall be returned.

[SWS_Dcm_00655]

[ ]

If the current session is a non-default session and a new diagnostic request with same or lower priority protocol than active one is detected, the Dcm shall act according [SWS_Dcm_00788], [SWS_Dcm_00789] and [SWS_Dcm_00790].

[SWS_Dcm_00656]

[ ]

If the current session is the default session and a diagnostic request is in execution, for any new diagnostic request with same or lower priority protocol than active one, the Dcm shall act according [SWS_Dcm_00788], [SWS_Dcm_00789] and [SWS_Dcm_00790].

Dcm_CopyRxData

[SWS_Dcm_00443]

[ ]

If Dcm_StartOfReception returns BUFREQ_OK, the further call to Dcm_CopyRxData shall copy the data from the buffer provided in info parameter) to the Dcm buffer and update the bufferSizePtr parameter with remaining free place in Dcm receive buffer after completion of this call.

[SWS_Dcm_00996]

[ ]

When the API Dcm_CopyRxData is invoked with SduLength from info equal to 0, the value BUFREQ_OK shall be returned and bufferSizePtr shall be filled with the remaining size of the Rx buffer.

Note:

The size of the Rx buffer is based on the buffer length, which is returned in the parameter RxBufferSizePtr of API Dcm_StartOfReception.

[SWS_Dcm_00342]

[ ]

After starting to copy the received data (see [SWS_Dcm_00443]), the Dcm module shall not access the receive buffer until it is notified by the service Dcm_TpRxIndication about the successful completion or unsuccessful termination of the reception.

Note:

Dcm_TpRxIndication is only expected when Dcm_StartOfReception succeeded

Dcm_TpRxIndication

[SWS_Dcm_00344]

[ ]

If Dcm_TpRxIndication is called with parameter Result different from E_OK, then the Dcm module shall not evaluate the buffer assigned to the I-PDU, which is referenced in parameter DcmRxPduId.

Rationale for [SWS_Dcm_00344]: It is undefined which part of the buffer contains valid data in this case

Concurrent TesterPresent ("keep alive logic")

It is possible, that functional "TesterPresent" commands are sent by the tester in parallel to physical requests/responses. This is called "keep alive logic" in ISO14229-1 [1]. This functional "TesterPresent" will be received on a separate DcmDslProtocolRxPduId belonging to a DcmDslProtocolRxPduId RxConnection which has DcmDslProtocolRxAddrType configured as DCM_FUNCTIONAL_TYPE, which is belonging to the same DcmDslConnection as the physical request. A Dcm-internal receive buffer which is not configured explicitly, is used in this case. Due to that reason, the functional TesterPresent (and only functional TesterPresent without response) is handled in the following way:

[SWS_Dcm_00112]

[RS_Diag_04249]

When the PduR module calls Dcm_TpRxIndication with parameter Result=E_OK (see [SWS_Dcm_00093]) and if the request is a "TesterPresent" command with "suppressPosRspMsgIndicationBit" set to TRUE (SID equal to 0x3E, subfunction equal to 0x80), the DSL submodule shall reset the session timeout timer (S3Server).

[SWS_Dcm_00113]

[ ]

When the PduR module calls Dcm_TpRxIndication with parameter Result = E_OK (see [SWS_Dcm_00093]) and if the request is a "TesterPresent" command with "suppressPosRspMsgIndicationBit" set to TRUE (SID equal to 0x3E, subfunction equal to 0x80), the DSL submodule shall not forward this request to the DSD submodule for further interpretation.

Rationale for [SWS_Dcm_00113]: Because of bypassing the functional "TesterPresent" in the DSL submodule, the Dcm module is able to receive and process next physical requests without any delay.

[SWS_Dcm_01168]

[ ]

The Dcm shall handle a tester present request as concurrent request only if it was received on a functional address with "suppressPosRspMsgIndicationBit" set to TRUE.

Dcm_CopyTxData

If the copied data is smaller than the length requested to transmit within the service PduR_DcmTransmit() the Dcm module will be requested by the service Dcm_CopyTxData to provide another data when the current copied data have been transmitted.

[SWS_Dcm_00346]

[ ]

If the function Dcm_CopyTxData is called and the Dcm module successfully copied the data in the buffer provided in info parameter, then the function shall return BUFREQ_OK.

[SWS_Dcm_00350]

[ ]

Caveats of Dcm_CopyTxData:

The value of parameter availableDataPtr of function Dcm_CopyTxData shall not exceed the number of Bytes still to be sent.

If this service returns BUFREQ_E_NOT_OK the transmit requests issued by calling the service PduR_DcmTransmit() is still not finished. A final confirmation (indicating an error with call of service Dcm_TpTxConfirmation) is required to finish this service and to be able to start another transmission (call to PduR_DcmTransmit()). So it is up to the transport protocol to confirm the abort of transmission.

Dcm_TpTxConfirmation

[SWS_Dcm_00352]

[ ]

If the function Dcm_TpTxConfirmation is called, then the Dcm module shall unlock the transmit buffer.

[SWS_Dcm_00353]

[ ]

If the function Dcm_TpTxConfirmation is called, then the Dcm module shall stop error handling (Page buffer timeout, P2ServerMax/P2*ServerMax timeout ).

For transmission via FlexRay the following restriction has to be considered: Since the FlexRay Specification does not mandate the existence of a transmit interrupt, the exact meaning of this confirmation (i.e. "transfer into the FlexRay controller's send buffer" OR "transmission onto the FlexRay network") depends on the capabilities of the FlexRay communication controller and the configuration of the FlexRay Interface.

Forward responses from the DSD submodule to the PduR module

[SWS_Dcm_00114]

[RS_Diag_04249]

The DSD submodule shall request the DSL submodule for transmission of responses.c(RS_Diag_04249)

[SWS_Dcm_00115]

[RS_Diag_04249]

When the diagnostic response of a DcmDslMainConnection is ready, the DSL submodule shall trigger the transmission of the diagnostic response to the PduR module by calling PduR_DcmTransmit() using the corresponding DcmDslProtocolTxPduRef parameter as PduId.

[SWS_Dcm_01072]

[ ]

In case of PeriodicTransmission, the Dcm shall provide in the call to PduR_DcmTransmit() the full payload data and expect no call to Dcm_CopyTxData.

[SWS_Dcm_01073]

[RS_Diag_04249]

In case of PeriodicTransmission, the Dcm will be called for periodic transmission with Dcm_TxConfirmation to indicate the transmission result.

Responses are sent with the DcmTxPduId, which is linked in the Dcm module configuration to the DcmDslProtocolRxPduId, i.e. the ID the request was received with (see configuration parameter DcmDslProtocolTx) Within PduR_DcmTransmit() only the length information and, for generic connections, the addressing information, is given to the PduR module. After the Dcm module has called successfully PduR_DcmTransmit(), the PduR module will call Dcm_CopyTxData to request the Dcm module to provide the data to be transmitted and will call Dcm_TpTxConfirmation after the complete PDU has successfully been transmitted or an error occurred. see section 7.4.4.5 "Generic Connection Handling for further details on address information handling within generic connections".

[SWS_Dcm_00117]

[RS_Diag_04249]

If the DSL submodule receives a confirmation after the complete Dcm PDU has successfully been transmitted or an error occurred by a call of Dcm_TpTxConfirmation, then the DSL submodule shall forward this confirmation to the DSD submodule.

[SWS_Dcm_00118]

[ ]

In case of a failed transmission (failed PduR_DcmTransmit() request) or error confirmation (Dcm_TpTxConfirmation with error), the DSD submodule shall not repeat the diagnostic response transmission.

Note:

Dcm_TpTxConfirmation is only expected when PduR_DcmTransmit succeeded.

[SWS_Dcm_01166]

[ ]

If the Multiplicity of DcmDslProtocolTx is set to "0" the Dcm shall process the received diagnostic request without sending a response.

More descriptions of the APIs (prototype, input/output parameter) can be found in the interface description of the PduR module [14].

Generic Connection Handling

The Dcm shall be able to handle generic connections, identified by DcmPdus with MetaDataItems of type SOURCE_ADDRESS_16 and TARGET_ADDRESS_16. These connections carry the actual tester address at run time. Generic connections are supported for diagnostics over IP and FlexRay diagnostics, and CAN diagnostics using normal fixed or mixed 29 bit addressing formats according to ISO15765-2 [15]. Depending on the actual layout of the CAN IDs, generic connections could also be used for extended or normal and mixed 11 bit addressing formats. The Dcm is not aware of the actual addressing format used by CanTp. Several connections may reference the same DcmPdus.

[SWS_Dcm_CONSTR_06044]

[ ]

Generic connections shall be consistent. This means that the MetaDataItems and the PduLength of all referenced PDUs of a DcmDslConnection (DcmDslProtocolRxPduRef, DcmDslProtocolTxPduRef, DcmDslPeriodicTxPduRef)are identical.

[SWS_Dcm_00848]

[ ]

The source address of diagnostic requests received via a generic connection must be stored. It is provided in the MetaDataItem SOURCE_ADDRESS_16 provided via Dcm_StartOfReception.

Target address for generic connection transmission

[SWS_Dcm_00849]

[RS_Diag_04153]

If the Dcm is about to send a response, response on event, or periodic message for a generic connection request, the Dcm shall set TARGET_ADDRESS_16 to the value of the stored source address in the MetaDataPtr in the PduR_DcmTransmit().

[SWS_Dcm_01429]

[ ]

The source address of diagnostic requests received via a generic connection shall be provided in the parameter TesterSourceAddress to the application [SWS_Dcm_01339], [SWS_Dcm_01340], [SWS_Dcm_01341], [SWS_Dcm_01342], [SWS_Dcm_00692], [SWS_Dcm_00694], [SWS_Dcm_00698]).

[SWS_Dcm_01347]

[RS_Diag_04153]

The target address of diagnostic requests received via a generic connection can be provided in the MetaDataItem TARGET_ADDRESS_16 received via Dcm_StartOfReception(). In this case, the Dcm shall ignore physical requests where the target address is not equal to the configured ECU address DcmDspProtocolEcuAddr.

[SWS_Dcm_01348]

[RS_Diag_04153]

The source address of the response transmitted via generic connections can be read from the configuration parameter DcmDspProtocolEcuAddr. It shall be provided to PduR_DcmTransmit() in the MetaDataItem SOURCE_ADDRESS_16, if that is configured for the transmit PDU.

Note:

If different source addresses are required for certain transmitted diagnostic messages of the same DcmDslProtocolRow, the MetaDataItem SOURCE_ADDRESS_16 can be omitted from the PDUs, and the address can then be configured in the lower layers. The same is possible for physical requests, where the TARGET_ADDRESS_16 can be omitted from the PDUs.

Guarantee timing to tester by sending busy responses

[SWS_Dcm_00024]

[RS_Diag_04016]

[RS_Diag_04249]

If the Application (or the DSP submodule) is able to perform a requested diagnostic task, but needs additional time to finish the task and prepare the response, then the DSL submodule shall send a negative response with NRC 0x78 (Response pending) when reaching the response time (DcmDspSessionP2ServerMax - DcmTimStrP2ServerAdjust respectively DcmDspSessionP2StarServerMax - DcmTimStrP2StarServerAdjust).

Rationale for [SWS_Dcm_00024]: The DSL submodule guarantees the response timing to tester.

[SWS_Dcm_00119]

[ ]

The DSL submodule shall send negative responses as required in [SWS_Dcm_00024] from a separate buffer.

Rationale for [SWS_Dcm_00119]: This is needed in order to avoid overwriting the ongoing processing of requests, e.g. the application already prepared response contents in the diagnostic buffer. The number of negative responses with NRC 0x78 (response pending) for one diagnostic request can be limited by the configuration parameter DcmDslDiagRespMaxNumRespPend to avoid endless NRC 0x78 transmission in case of an application deadlock.

[SWS_Dcm_01567]

[ ]

The maximum number of negative responses with NRC 0x78 can be configured using the optional configuration parameter DcmDslDiagRespMaxNumRespPend (see ECUC_Dcm_00693). If this parameter is not configured, the default amount of negative responses with NRC 0x78 is infinite.

Support of periodic transmission

The UDS service ReadDataByPeriodicIdentifier (0x2A) allows the tester to request the periodic transmission of data record values from the ECU identified by one or more periodicDataIdentifiers.

[SWS_Dcm_00122]

[ ]

The Dcm module shall send responses for periodic transmissions using a separate protocol and a separate buffer of configurable size.

The DcmDslPeriodicTransmissionConRef configuration parameter allows linking the protocol used to receive the periodic transmission request / transmit the periodic transmission response to the protocol used for the transmission of the periodic transmission messages. Note that multiple DcmTxPduIds can be assigned to the periodic transmission protocol. The Dcm module respects several restrictions according to the communication mode:

[SWS_Dcm_00123]

[ ]

Periodic transmission communication shall only take place in Full Communication Mode.

Periodic transmission events can occur when not in Full Communication Mode. So the following requirement exists:

[SWS_Dcm_00125]

[ ]

The Dcm module shall discard periodic transmission events beside Full Communication Mode and shall not queue it for transmission.

[SWS_Dcm_00126]

[ ]

Periodic transmission events shall not activate the Full Communication Mode.

Support of segmented response (paged-buffer)

[SWS_Dcm_00028]

[ ]

If enabled (DcmPagedBufferEnabled=TRUE), the Dcm module shall provide a mechanism to send responses larger than the configured and allocated diagnostic buffer.

Dependency for DcmDslProtocolMaximumResponseSize

[SWS_Dcm_CONSTR_06055]

[ ]

DcmDslProtocolMaximumResponseSize shall be only present if DcmPagedBufferEnabled is set to TRUE.

[SWS_Dcm_01058]

[ ]

If DcmPagedBufferEnabled == TRUE and the generated Response for a Request is longer than DcmDslProtocolMaximumResponseSize, the Dcm shall respond with NRC 0x14 (DCM_E_RESPONSETOOLONG).

[SWS_Dcm_01059]

[ ]

If DcmPagedBufferEnabled == FALSE and the generated Response for a Request is longer than Dcm_MsgContextType structure element resMaxDataLen, the Dcm shall respond with NRC 0x14 (DCM_E_RESPONSETOOLONG) .

With paged-buffer handling the ECU is not forced to provide a buffer, which is as large as the maximum length of response. Please note:

paged-buffer handling is for transmit only - no support for reception.

paged-buffer handling is not available for the Application (DCM-internal use only).

[SWS_Dcm_01186]

[RS_Diag_04147]

The Dcm shall provide the correct amount of Data requested by the TP or return BUFREQ_E_BUSY in case the requested amount of data is not available.

Note:

In case the requested amount of data is not available, the Dcm should fill up the paged buffer immediately.

Support of ResponsePending response triggered by the Application

In some cases, e.g. in case of routine execution, the Application needs to request an immediate NRC 0x78 (Response pending), which shall be sent immediately and not just before reaching the response time (P2ServerMax respectively P2*ServerMax).

When the Dcm module calls an operation and gets an error status DCM_E_FORCE_RCRRP, the DSL submodule will trigger the transmission of a negative response with NRC 0x78 (Response pending). This response needs to be sent from a separate buffer, in order to avoid overwriting the ongoing processing of the request.

Manage security level

[SWS_Dcm_00020]

[RS_Diag_04005]

The DSL submodule shall save the level of the current active security level.

For accessing this level, the DSL submodule provides interfaces to:

get the current active security level: Dcm_GetSecurityLevel

set a new security level: DslInternal_SetSecurityLevel()

[SWS_Dcm_00033]

[SRS_BSW_00101]

[RS_Diag_04005]

During Dcm initialization the security level is set to the value 0x00 (DCM_SEC_LEV_LOCKED).

[SWS_Dcm_00139]

[ ]

The DSL shall reset the security level to the value 0x00 (i.e. the security is enabled) under one of the following conditions: - if a transition from any diagnostic session other than the defaultSession to another session other than the defaultSession (including the currently active diagnostic session) is performed or - if a transition from any diagnostic session other than the defaultSession to the defaultSession (DslInternal_SetSecurityLevel()) (initiated by UDS Service DiagnosticSessionControl (0x10) or S3Server timeout) is performed.

Only one security level can be active at a time.

[SWS_Dcm_01329]

[ ]

On every security level change the Dcm shall update the ModeDeclarationGroup DcmSecurityAccess with the new security level.

Dependency on DcmDspSecurityAttemptCounterEnabled

[SWS_Dcm_CONSTR_06083]

[RS_Diag_04005]

If DcmDspSecurityNumAttDelay is not configured, the DcmDspSecurityAttemptCounterEnabled on the same DcmDspSecurityRow shall be set to FALSE.

[SWS_Dcm_CONSTR_06101]

[ ]

DcmDspSecurityResetAttemptCounterOnTimeout shall be present only if the DcmDspSecurityAttemptCounterEnabled for DcmDspSecurityRow is set to TRUE.

Initialization sequence

[SWS_Dcm_01154]

[ ]

At initialization, for each DcmDspSecurityRow entry for which the DcmDspSecurityAttemptCounterEnabled configuration parameter is set to TRUE, the corresponding Xxx_GetSecurityAttemptCounter shall be called in order to get the value of the AttemptCounter for each of these DcmDspSecurityRow entries.

[SWS_Dcm_01156]

[ ]

If Xxx_GetSecurityAttemptCounter has returned E_NOT_OK the attempt counter shall be set to the value configured in DcmDspSecurityNumAttDelay of the according SecurityLevel.

[SWS_Dcm_01351]

[ ]

If any Xxx_GetSecurityAttemptCounter operation returns a DCM_E_PENDING value, the Dcm shall interrupt calling the Xxx_GetSecurityAttemptCounter() in order to resume this chain of calls within the next Dcm_MainFunction() cycle.

Note:

this may be the case when these values are stored within some specific nonvolatile memory.

Dependency for DcmDspSecurityGetAttemptCounterFnc

[SWS_Dcm_CONSTR_06076]

[ ]

DcmDspSecurityGetAttemptCounterFnc shall be present only if DcmDspSecurityUsePort is set to USE_ASYNCH_FNC and DcmDspSecurityAttemptCounterEnabled is set to TRUE.

[SWS_Dcm_01352]

[ ]

If the delay after the first call of the Dcm_MainFunction() which is configured in DcmDspSecurityMaxAttemptCounterReadoutTime has been reached and all the Xxx_GetSecurityAttemptCounter have not been called yet (i.e. one operation has returned a DCM_E_PENDING status in the previous Dcm_MainFunction() cycle), the pending operation shall be cancelled by a call with the OpStatus set to DCM_CANCEL.

[SWS_Dcm_01353]

[ ]

In the conditions of [SWS_Dcm_01352], the AttemptCounters of remaining security levels (which have not been obtained via the calls to their Xxx_GetSecurityAttemptCounter) shall be initialized with the value configured in DcmDspSecurityNumAttDelay of the according SecurityLevel.

[SWS_Dcm_01354]

[ ]

While not all Xxx_GetSecurityAttemptCounter operations have returned a final status and the operation chain has not been cancelled, the conditionsNotCorrect (0x22) NRC shall be returned to any SecurityAccess (0x27) requestSeed subfunction request.

[SWS_Dcm_01355]

[ ]

Once all the AttemptCounter values have been successfully or unsuccessfully retrieved (all the Xxx_GetSecurityAttemptCounter() operations have been executed and have returned a final, non-PENDING error value or the operation chain has been cancelled), if at least one of the restored AttemptCounter values is greater than or equal to the DcmDspSecurityNumAttDelay configured for its corresponding DcmDspSecurityRow, the Dcm shall start the SecurityDelayTimer with the higher value of DcmDspSecurityDelayTimeOnBoot / DcmDspSecurityDelayTime of the according DcmDspSecurityRow.

[SWS_Dcm_01356]

[ ]

A timer (DcmDspSecurityDelayTime, DcmDspSecurityMaxAttemptCounterReadoutTime) which is configured with 0 shall be considered to have timed out instantaneously when it is started, i.e. shall have no delay effect.

Dependency for DcmDspSecurityMaxAttemptCounterReadoutTime

[SWS_Dcm_CONSTR_06074]

[ ]

DcmDspSecurityMaxAttemptCounterReadoutTime shall be a multiple and at minimum equal to DcmTaskTime.

AttemptCounter update

[SWS_Dcm_01357]

[ ]

A successful sendKey subfunction request shall reset that security level's specific AttemptCounter.

[SWS_Dcm_01599]

[ ]

If DcmDspSecurityResetAttemptCounterOnTimeout is set to TRUE and SecurityDelayTimer expires, the Dcm shall reset that security level's specific AttemptCounter.

[SWS_Dcm_01155]

[ ]

The Dcm shall call Xxx_SetSecurityAttemptCounter() (in case the configuration parameter DcmDspSecurityAttemptCounterEnabled for the according DcmDspSecurityRow is set to TRUE) when the Dcm has changed the attempt counter to inform the application about the counter change.

Dependency for DcmDspSecuritySetAttemptCounterFnc

[SWS_Dcm_CONSTR_06078]

[ ]

DcmDspSecuritySetAttemptCounterFnc shall be present only if DcmDspSecurityUsePort is set to USE_ASYNCH_FNC and the DcmDspSecurityAttemptCounterEnabled set to TRUE.

Manage session state

[SWS_Dcm_00022]

[RS_Diag_04006]

The DSL submodule shall save the state of the current active session.

For accessing this variable, the DSL submodule provides interfaces to:

get the current active session: Dcm_GetSesCtrlType

set a new session: DslInternal_SetSesCtrlType()

[SWS_Dcm_00034]

[SRS_BSW_00101]

During Dcm initialization, the session state is set to the value 0x01 ("DefaultSession").

[SWS_Dcm_01062]

[ ]

The call to Dcm_ResetToDefaultSession allows the application to reset the current session to Default session and invokes the mode switch of the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl by calling SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnostic SessionControl_DCM_DEFAULT_SESSION).

Example:

Automatic termination of an extended diagnostic session upon exceeding of a speed limit.

Manage authentication state

The Dcm provides means for authenticated diagnostics. The DSL sub-module provides an authentication state per diagnostic connection. It initializes this state upon startup and takes care about fallback into non-authenticated states if the connection is idle for some time.

Authentication state per connection

[SWS_Dcm_01477] dThe Dcm shall provide an authentication state per configured DcmDslConnection.c(RS_Diag_04230)

Mode declaration group per authentication state

[SWS_Dcm_01478]

[RS_Diag_04230]

The Dcm shall provide the state of each authentication state via the ModeDeclarationGroupPrototype DcmAuthentication_<ConnectionName>.

The Dcm maintains an authentication state and mirrors this state to the mode declaration group DcmAuthentication_<ConnectionName>. This mode declaration group is intended to be changed only by the Dcm, however applications changing this state have no influence on the Dcm authentication state.

Authentication states

[SWS_Dcm_01479]

[RS_Diag_04230]

The Dcm shall support per connection the two authentication states:

deauthenticated

authenticated

Upon startup, the Dcm is in deauthenticated state or restores the persisted state. A transition to authenticated state can only be done after the client successfully executed the authentication sequence. In some use cases as in production, a frequent power-on/power off sequence is performed. To keep the achieved authentication state over the power off, there is a dedicated mode rule requesting the Dcm to persist the authenticated state.

Initialization of authentication state

[SWS_Dcm_01480]

[RS_Diag_04230]

If DcmDspAuthenticationPersistStateModeRuleRef is not configured or the mode rule referenced by DcmDspAuthenticationPersistStateModeRuleRef is evaluated to false, the Dcm shall initialize within Dcm_Init all authentication states to deauthenticated state.

Initialization of persisted authentication states

[SWS_Dcm_01481]

[RS_Diag_04230]

If the mode rule referenced by DcmDspAuthenticationPersistStateModeRuleRef is evaluated to true, the Dcm shall initialize the persisted authentication state including role and white list on each connection.

Transitions between authenticated states are controlled by both DSL and DSP submodules. The DSL sub-module is in charge for fallback of authenticated state into deauthenticated state. The DSP sub-module is in charge for transition changes triggered from a client by diagnostic services.

Figure 7.7: Authenticated state transitions without persistent states

Fallback to deauthenticated session on idle connection

[SWS_Dcm_01482]

[RS_Diag_04230]

The Dcm shall make a transition from authenticated into deauthenticated state for a configured connection if the following conditions apply:

The Dcm was in default session when the last diagnostic response was send on that connection and

DcmDspAuthenticationDefaultSessionTimeOut is configured and no valid diagnostic request was received on that connection for DcmDspAuthenticationDefaultSessionTimeOut seconds after the last Dcm_TpTxConfirmation on that connection.

Fallback to deauthenticated session on S3server timeout

[SWS_Dcm_01483]

[RS_Diag_04230]

If the Dcm is in a non-default session and a S3server timeout occurs, the Dcm shall perform a transition from authenticated into deauthenticated state on the authentication state assigned to that connection which was in a non-default session.

Clearing persisted authentication state

[SWS_Dcm_01484]

[RS_Diag_04230]

If the authentication state of a connection performs a transition to deauthenticated state, the Dcm shall clear all persisted authentication information on that connection.

Reaction of fallback into deauthenticated state

[SWS_Dcm_01485]

[RS_Diag_04230]

Upon a transition from authenticated into deauthenticated state, the Dcm shall discard the current role, white list and use the configured deauthentication role from DcmDspAuthenticationDeauthenticatedRoleRef.

In some use cases, it is desirable that the application set the role instead of using a diagnostic service with its potentially time-consuming certificate parsing. The Dcm provides the API Dcm_SetDeauthenticatedRole to overwrite the configured deauthentication role. The overwritten role is only valid in deauthenticated state will not be persisted and is overwritten by a role provided by certificates via service 0x29.

Default authentication role set from SWC

[SWS_Dcm_01486]

[RS_Diag_04230]

If a connection is in deauthenticated state and the API Dcm_SetDeauthenticatedRole is called, the Dcm shall use the provided deauthenticatedRole as new role per deauthenticated state for this connection.

Setting deauthenticated role by SWC only in deauthenticated state

[SWS_Dcm_01487]

[RS_Diag_04230]

The Dcm shall process a call of Dcm_SetDeauthenticatedRole only if the connection is in deauthenticated state.

Lifetime of deauthenticated role by SWC

[SWS_Dcm_01488]

[RS_Diag_04230]

A deauthenticated role set by Dcm_SetDeauthenticatedRole is discarded when that connection performs a transition authenticated state.

No persistency for deauthenticated roles by SWC

[SWS_Dcm_01489]

[RS_Diag_04230]

At startup the ECU shall always use the deauthentication state configured in DcmDspAuthenticationDeauthenticatedRoleRef.

Keep track of active non-default sessions

[SWS_Dcm_00140]

[ ]

Whenever a non-default session is active and when the session timeout (S3Server) is reached without receiving any diagnostic request, the DSL submodule shall reset to the default session state ("DefaultSession", 0x01) and invoke the the mode switch of the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl by calling SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnosticSessionControl_DEFAULT_SESSION) .

Note:

<bsnp> is the BSW Scheduler Name Prefix

The start / stop of S3Server timeout timer is processed as follows:

[SWS_Dcm_00141]

[RS_Diag_04249]

Subsequent start:

Completion of any final response message or an error indication (Dcm_TpTxConfirmation: confirmation of complete PDU or indication of an error)

Completion of the requested action in case no response message (positive and negative) is required / allowed.

Indicates an error during the reception of a multi-frame request message.(Dcm_TpRxIndication: indication of an error)

Subsequent stop:

Start of a multi-frame request message (Dcm_StartOfReception: indicates start of PDU reception)

Reception of single-frame request message. (Dcm_StartOfReception: indicates start of PDU reception)

"Start of S3Server" means reset the timer and start counting from the beginning.

Allow to modify timings

[SWS_Dcm_00027]

[RS_Diag_04015]

[RS_Diag_04249]

The Dcm module shall handle the following protocol timing parameters in compliance with ISO14229-2 [13]: P2ServerMin, P2ServerMax, P2*ServerMin, P2*ServerMax, S3Server

[SWS_Dcm_00143]

[RS_Diag_04015]

[RS_Diag_04249]

P2min / P2*min and S3Server shall be set to defined values: P2min = 0ms, P2*min = 0ms, S3Server = 5s.

These protocol timing parameters have influence on the session layer timing (no influence on Transport Layer timing). Some of these timing parameters can be modified while protocol is active with the following means:

UDS Service DiagnosticSessionControl (0x10)

UDS Service AccessTimingParameter (0x83)

The DSL submodule provides the following functionalities to modify the timing parameters:

Provide the active timing parameters,

Set the new timing parameters. Activation of new timing values is only allowed after sending the response.

Different service tables

For the different protocols a different set of allowed diagnostic services is valid (e.g. the UDS commands for the enhanced diagnosis, the OBD mode services for the OBD protocol). It is possible to create different service tables and link them to the diagnostic protocol.

[SWS_Dcm_00035]

[SRS_BSW_00101]

With every protocol initialization, the DSL submodule sets a link to the corresponding service table (see configuration parameter DcmDslProtocolSIDTable).

The DSD submodule uses this link for further processing of diagnostic requests.

Prioritization of protocol

The configuration parameter DcmDslProtocolPriority makes it possible to give each protocol its own relative priority. Possible use case: There are ECUs, communicating with a vehicle-internal diagnostic tester (running on enhanced diagnosis) and a vehicle-external OBD-II/WWH-OBD tester. The OBD-II/WWH-OBD communication must have a higher priority than the enhanced diagnosis.

[SWS_Dcm_00015]

[RS_Diag_04021]

A protocol with higher priority is allowed to preempt the already running protocol.

Differentiation of diagnostic protocols is possible, because of different DcmDslProtocolRxPduId values (configured per protocol, see configuration parameter DcmDslProtocolRxPduRef) referenced in the protocol configuration.

Preemption of protocol

Callback notification for preempted protocols

[SWS_Dcm_00459]

[RS_Diag_04021]

If a running diagnostic request is preempted by a higher priority request, the DSL submodule shall call all configured Xxx_StopProtocol() functions on the preempted protocol.

XXX_StopProtocol functions are configured via the configuration parameter DcmDslCallbackDCMRequestService. Protocol preemption can't be activated with a Concurrent TesterPresent of a higher priority protocol (see also [SWS_Dcm_01146]).

[SWS_Dcm_00079]

[RS_Diag_04021]

If a protocol is preempted and this protocol has a running pending response transmission, the Dcm shall call PduR_DcmCancelTransmit () for this transmission with the following parameters: PduId: the id of the Pdu to be canceled

[SWS_Dcm_00460]

[RS_Diag_04021]

When PduR_DcmCancelTransmit() returns E_NOT_OK, the Dcm module shall stop the current protocol.

[SWS_Dcm_01046]

[RS_Diag_04021]

If a running diagnostic request is preempted by a higher priority request, the Dcm shall cancel all external pending operations on the preempted protocol with Dcm_OpStatus set to DCM_CANCEL.

[SWS_Dcm_01047]

[ ]

In case an operation to the Dem is pending and the new request also requires an interaction with the Dem, the Dcm shall accept the new request and call the corresponding Dem API with the parameters from the new request.

[SWS_Dcm_00575]

[RS_Diag_04021]

If the Dcm is preempting a protocol with a pending reception, the Dcm module shall call cancel that reception with PduR_DcmCancelReceive().

[SWS_Dcm_00576]

[RS_Diag_04021]

If PduR_DcmCancelReceive () returns E_NOT_OK, the Dcm shall stop the current protocol.

[SWS_Dcm_00625]

[ ]

A Low-priority or same-priority request can preempt a higher priority protocol if this higher priority protocol is in default session and no active request is in execution phase. In this case the DSL submodule shall call all configured Xxx_StopProtocol() functions (see configuration parameter DcmDslCallbackDCMRequestService).

[SWS_Dcm_00728]

[ ]

The handling of protocols with equal priority shall be possible.

[SWS_Dcm_00727]

[RS_Diag_04021]

If a diagnostic request cannot be processed due to a higher priority protocol and DcmDslDiagRespOnSecondDeclinedRequest is set to True, the Dcm shall send NRC 0x21 (BusyRepeatRequest) for the not processed request.

[SWS_Dcm_01605]

[RS_Diag_04021]

If a diagnostic cannot be processed due to a higher priority protocol and DcmDslDiagRespOnSecondDeclinedRequest is set to False, the Dcm shall ignore the request. In this case no response message at all is generated.

[SWS_Dcm_00729]

[ ]

In case of multiple clients with different PduIDs which are requesting the same protocol, as all the connections of the same protocol are having the same priority, a second request (with the different RxPduId) will not be processed. If the configuration parameter DcmDslDiagRespOnSecondDeclinedRequest is TRUE, a negative response with NRC 0x21 (BusyRepeatRequest) shall be issued for the second request. If the configuration parameter is FALSE, no response shall be issued.

Note:

A multitude of RxPduIDs may be configured per DcmDslProtocol

These RxPduIDs may be themselves connected to different Testers via the PduR configuration

This means that many Testers may be configured for the same Protocol

And this represents a non-UDS extension/use case. In order to have a UDScompliant flow, there should be one DcmDslProtocol instance per Tester.

[SWS_Dcm_01050]

[ ]

In case of diagnostic parallel requests, with same / lower priority than the active request then the ComM APIs (ComM_DCM_ActiveDiagnostic, ComM_DCM_InactiveDiagnostic) shall not be called.

Parallel diagnostic protocol processing

Multiple testers are a common scenario in today's vehicles. In order to reduce the interference between concurrent tester requests to a minimum the Dcm supports parallel diagnostic service processing. This behavior is according to recommended practice of ISO 14229-1 Appendix J. There are certain restrictions, that in non-default session only diagnostic communication from one tester is allowed. In default session and for OBD-II communication it is possible to process diagnostic requests in parallel. Parallel OBD and UDS communication is particularly important if vehicles are equipped with so called 'OBD dongles' or with electronical logging devices. These devices are installed by the vehicle owner and do diagnostic communication over standardized OBD services. The presence of such devices shall interfere as little as possible with vehicle internal UDS communication. Therefore, whenever it is possible, the Dcm supports parallel processing.

Processing of parallel requests in default session

[SWS_Dcm_01602]

[RS_Diag_04021]

If the Dcm receives a request and no further protocol with a higher priority is currently in a non-default session, the Dcm shall accept the new incoming request and process it.

No parallel processing in non-default session

[SWS_Dcm_01603]

[RS_Diag_04021]

If the Dcm receives a request and a further protocol with a higher priority is currently in a non-default session, the Dcm shall decline the new received request according to [SWS_Dcm_00727].

Some Dcm interfaces provide access to different diagnostic services, e.g. interface RoutineService for subfunctions Start, Stop and Request Result of a RoutineControl (0x31) or the interface DataServices for the Read and Write operations. On these interfaces only a single client shall access to the data at any point in time.

Delay parallel processing on the same interface

[SWS_Dcm_01604]

[RS_Diag_04021]

If the Dcm receives a request and the service processing of this request requires a call to the same interface that is currently processing another request, the Dcm shall delay the call to the interface until the running operation on that interface has finished.

If the Dcm delays the service processing due to [SWS_Dcm_01604] the standard timing behavior with P2 and NRC 0x78 apply. From an outside perspective, the delayed call to the application looks like that the application itself is taking more time for execution.

[SWS_Dcm_01367]

[RS_Diag_04163]

The Dcm shall process incoming OBD-II requests in parallel to a running UDS request. In this case the protocol priority check according to [SWS_Dcm_00015] is skipped and no protocol pre-emption is done.

With the container DcmDslProtocolRow, the Dcm configuration supports multiple protocols. Each protocol has a configured DcmDemClientRef defining the Dem client interacting with the Dem. This client Id allows the Dem to distinguish between concurrent calls of the Dcm of the same function or set of functions to process a certain request.

[SWS_Dcm_01369]

[RS_Diag_04162]

While processing a diagnostic request received from a given protocol, the Dcm shall determine the DcmDemClientRef of the DcmDslProtocolRow of the processed protocol. The Dcm shall use this value in all Dem API calls that have a ClientId as parameter.

Serialization of multiple calls to the same interface

[SWS_Dcm_01370]

[RS_Diag_04162]

The Dcm shall internally serialize all asynchronous C/S interface or C function calls to the same port interface or C function during parallel diagnostic services processing and return a pending to the re-entrant caller.

[SWS_Dcm_01371]

[RS_Diag_04162]

If the Dcm receives a request on a higher priority protocol than the currently processed request and a diagnostic service in a non-default session is currently processed, the Dcm shall cancel the running diagnostic request, make a transition into default session and process the new received request.

Integrators will assign OBD protocols the highest priority to meet the legislated response and timing requirements. Therefore, all definitions of 'higher priority protocols' apply to the use case where OBD is used.

[SWS_Dcm_01372]

[RS_Diag_04162]

If the Dcm processes a request from a high priority protocol in default session and the Dcm is receiving a diagnostic request to change in a nondefault session, the Dcm shall delay the session change request until the high priority protocol service is finished according to [SWS_Dcm_01371] and make a transition into the requested non-default session.

Limitation to one single OBD protocol

[SWS_Dcm_CONSTR_06102]

[ ]

The Dcm shall support only one DcmDslProtocolRow with a configured DcmDslProtocolType set to DCM_OBD_ON_<XYZ>.

OBD procotol shall have highest priority

[SWS_Dcm_CONSTR_06103]

[ ]

The Dcm shall support a DcmDslProtocolRow with DcmDslProtocolType set to DCM_OBD_ON_<XYZ> as the highest priority.

Detection of protocol start

[SWS_Dcm_00036]

[SRS_BSW_00101]

With first request of a diagnostic protocol, the DSL submodule shall call all configured Xxx_StartProtocol() functions (see configuration parameter DcmDslCallbackDCMRequestService).

Inside this function, the Application can examine the environment conditions and enable/disable further processing of the protocol.

[SWS_Dcm_00144]

[RS_Diag_04015]

After all Xxx_StartProtocol() functions have returned E_OK (meaning all components have allowed the start of the protocol), the default timing parameters are loaded from the default session configuration (see configuration parameter DcmDspSessionRow).

Harmonize the naming between interfaces and modes

[SWS_Dcm_CONSTR_06000]

[ ]

The shortname of DcmDspSessionRow shall match names of Dcm_SesCtrlType and of the mode declarations of DcmDiagnosticSessionControl. The "DCM_" prefix is mandatory for all shortnames.

Provide standardized names for ISO standardized diagnostic sessions

[SWS_Dcm_CONSTR_06001]

[ ]

The following values of DcmDspSessionLevel which represent ISO defined diagnostic sessions shall be used for the shortname of DcmDspSessionRow:

DCM_DEFAULT_SESSION

DCM_PROGRAMMING_SESSION

DCM_EXTENDED_DIAGNOSTIC_SESSION

DCM_SAFETY_SYSTEM_DIAGNOSTIC_SESSION

[SWS_Dcm_00145]

[ ]

After all Xxx_StartProtocol() functions have returned E_OK (meaning all components have allowed the start of the protocol), the service table is set (see configuration parameter DcmDslProtocolSIDTable).

[SWS_Dcm_00146]

[ ]

After all Xxx_StartProtocol() functions have returned E_OK (meaning all components have allowed the start of the protocol), the security state is reset.

[SWS_Dcm_00147]

[ ]

After all Xxx_StartProtocol() functions have returned E_OK (meaning all components have allowed the start of the protocol), the session state is reset to default session. Furthermore the Dcm module shall invoke the the mode switch of the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl by calling SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnosticSessionControl_DEFAULT_SESSION) .

Note:

<bsnp> is the BSW Scheduler Name Prefix

[SWS_Dcm_00674]

[ ]

If Xxx_StartProtocol() doesn't return E_OK, the Dcm shall return NRC 0x22.

Protocol stop

A protocol stop can appear only in case of protocol preemption (see chapter 7.4.4.14.3 Preemption of protocol).

[SWS_Dcm_00624]

[ ]

With the reception of Dcm_TpTxConfirmation connected to the response given by the DSL submodule, the Dcm shall not stop the current protocol (no call to xxx_StopProtocol).

Note:

A protocol (e.g. OBD) will be active till reset or other protocol preempts.

[SWS_Dcm_01190]

[ ]

If Xxx_StopProtocol() doesn't return E_OK, the Dcm shall return NRC 0x22.

Manage resources

Due to limited resources, the following points should be considered as hints for the design:

It is allowed to use and allocate only one diagnostic buffer in the Dcm module. This buffer is then used for processing the diagnostic requests and responses.

Output of NRC 0x78 (Response pending) responses is done with a separate buffer.

paged-buffer handling (see [SWS_Dcm_00028]).

Communication Mode Handling

Communication Mode Handling is an interface between Dcm and ComM. The ComM informs the Dcm about the current communication state of a channel. The Dcm is calling the ComM about active Diagnostic which shall prevent an Ecu shutdown/sleep.

The status ActiveDiagnostic shows if diagnostic requests shall keep the ECU awake (ActiveDiagnostic =='DCM_COMM_ACTIVE') or if diagnostic requests shall not prevent an Ecu shutdown/sleep (ActiveDiagnostic =='DCM_COMM_NOT_ACTIVE'). Application can change the status ActiveDiagnostic regarding to system conditions.

[SWS_Dcm_CONSTR_06027]

[ ]

The application will inform the Dcm by calling Xxx_SetActiveDiagnostic() about the ActiveDiagnostic status.

[SWS_Dcm_01069]

[ ]

After Dcm_Init, the Dcm shall set ActiveDiagnostic to 'DCM_COMM_ACTIVE'.

[SWS_Dcm_01070]

[ ]

If Xxx_SetActiveDiagnostic() is called with 'false' the Dcm set ActiveDiagnostic to 'DCM_COMM_NOT_ACTIVE'.

[SWS_Dcm_01071]

[ ]

If Xxx_SetActiveDiagnostic() is called with 'true' the Dcm set ActiveDiagnostic to 'DCM_COMM_ACTIVE'.

[SWS_Dcm_01142]

[ ]

The Dcm shall wait the Full Communication mode indication from the ComM (call to Dcm_ComM_FullComModeEntered) before initiating the transmission of the diagnostic answer. The time to wait should be no longer than the P2ServerMax calculated from the moment the request was received.

[SWS_Dcm_01143]

[ ]

If the Dcm fails to confirm a response pending transmission (DCM_E_FORCE_RCRRP) due to [SWS_Dcm_01142], the Dcm shall trigger the Det error DCM_E_FORCE_RCRRP_IN_SILENT_COMM.

Note :

On the reception side a silent communication mode can lead to the lost of the request in case of segmented transmission.

No Communication

The ComM module will indicate the No Communication Mode to the Dcm module by calling Dcm_ComM_NoComModeEntered. In response, the Dcm will immediately disable all transmissions (see the definition of Dcm_ComM_NoComModeEntered for details).

[SWS_Dcm_00148]

[ ]

Dcm_ComM_NoComModeEntered shall disable all kinds of transmissions (receive and transmit) of communication. This means that the message reception and also the message transmission shall be off.

[SWS_Dcm_00149]

[ ]

Dcm_ComM_NoComModeEntered shall disable the ResponseOnEvent transmissions.

[SWS_Dcm_00150]

[ ]

Dcm_ComM_NoComModeEntered shall disable the periodicId transmissions (ReadDataByPeriodicIdentifier).

[SWS_Dcm_00151]

[ ]

Dcm_ComM_NoComModeEntered shall disable normal transmissions.

[SWS_Dcm_00152]

[ ]

After Dcm_ComM_NoComModeEntered has been called, the Dcm module shall not call the function PduR_DcmTransmit().

[SWS_Dcm_01324]

[ ]

In case Dcm_ComM_NoComModeEntered is called with a NetworkId for a ComM channel not referenced within the Dcm (see configuration parameter DcmDslProtocolComMChannelRef), the Dcm shall return without performing any further action.

Silent Communication

The ComM module will indicate the Silent Communication Mode to the Dcm module by calling Dcm_ComM_SilentComModeEntered. In response, the Dcm will immediately disable all transmissions (see the definition of Dcm_ComM_SilentComModeEntered for details).

[SWS_Dcm_00153]

[ ]

Dcm_ComM_SilentComModeEntered shall disable all transmission. This means that the message transmission shall be off.

[SWS_Dcm_00154]

[ ]

Dcm_ComM_SilentComModeEntered shall disable the ResponseOnEvent transmissions.

[SWS_Dcm_00155]

[ ]

Dcm_ComM_SilentComModeEntered shall disable the periodicId transmissions (ReadDataByPeriodicIdentifier) shall be disabled.

[SWS_Dcm_00156]

[ ]

Dcm_ComM_SilentComModeEntered shall disable the normal transmissions.

[SWS_Dcm_01325]

[ ]

In case Dcm_ComM_SilentComModeEntered is called with a NetworkId for a ComM channel not referenced within the Dcm (see configuration parameter DcmDslProtocolComMChannelRef), the Dcm shall return without performing any further action.

Full Communication

The ComM module will indicate the Full Communication Mode to the Dcm module by calling Dcm_ComM_FullComModeEntered. In response, the Dcm will enable all transmissions (see the definition of Dcm_ComM_FullComModeEntered for details).

[SWS_Dcm_00157]

[ ]

Dcm_ComM_FullComModeEntered shall enable all kind of communication. This means that the message reception and also the message transmission shall be on.

[SWS_Dcm_00159]

[ ]

Dcm_ComM_FullComModeEntered shall enable the ResponseOnEvent transmissions.

[SWS_Dcm_00160]

[ ]

Dcm_ComM_FullComModeEntered shall enable the periodicId transmissions (ReadDataByPeriodicIdentifier).

[SWS_Dcm_00161]

[ ]

Dcm_ComM_FullComModeEntered shall enable the normal transmissions.

[SWS_Dcm_00162]

[ ]

After Dcm_ComM_FullComModeEntered has been called, the Dcm shall handle the functions DslInternal_ResponseOnOneDataByPeriodicId() or DslInternal_ResponseOnOneEvent() without restrictions.

[SWS_Dcm_01326]

[ ]

In case Dcm_ComM_FullComModeEntered is called with a NetworkId for a ComM channel not referenced within the Dcm (see configuration parameter DcmDslProtocolComMChannelRef), the Dcm shall return without performing any further action.

Diagnostic Activation State

The Dcm notifies the ComM module about the internal diagnostic state for all networks. There are two options for the diagnostic state on a network. In 'active' diagnostic state, the Dcm is processing one or more diagnostic requests from this network or the Dcm is in a non-default session. In 'inactive' diagnostic state, the Dcm is in default session and is not processing a diagnostic request on that network.

When a network has no communication in progress, the Dcm will set the diagnostic activation state to 'inactive'. When there is a diagnostic communication on a network the Dcm sets the diagnostic state to 'active'. In any non-default session, the diagnostic state remains in state 'active'. The communication state can also be controlled by the API Xxx_SetActiveDiagnostic according to [SWS_Dcm_01070] and [SWS_Dcm_01071].

[SWS_Dcm_01373]

[RS_Diag_04006]

The Dcm shall go into 'active' diagnostic state on a network, if a diagnostic request is received on a network or the diagnostic session is changed to any non-default session.

[SWS_Dcm_01374]

[RS_Diag_04006]

The Dcm shall go into 'inactive' diagnostic state on a network when the current diagnostic request processing is finished and the Dcm is not processing a diagnostic request of another protocol on this network and if the Dcm is in default session.

[SWS_Dcm_01375]

[RS_Diag_04006]

The Dcm shall go into 'inactive' diagnostic state on all networks if a S3Server timeout occurs and the Dcm makes a transition into default session.

[SWS_Dcm_01376]

[RS_Diag_04006]

If ActiveDiagnostic is 'DCM_COMM_ACTIVE' and the Dcm is doing a transition into 'active' diagnostic state of a diagnostic protocol, the Dcm shall call ComM_DCM_ActiveDiagnostic(NetworkId), with the networkId associated to the received Pdu (see DcmDslProtocolComMChannelRef), with every request, to inform the ComM module about the need to stay in Full Communication Mode.

[SWS_Dcm_01377]

[RS_Diag_04006]

Upon a diagnostic state transition into 'inactive', the Dcm shall notify the ComM module about an inactive diagnostic state on a network by calling ComM_DCM_InactiveDiagnostic(NetworkId), with the networkId associated to the received Pdu (see DcmDslProtocolComMChannelRef).

[SWS_Dcm_01378]

[RS_Diag_04006]

The definition of a finished diagnostic request according to [SWS_Dcm_01374], shall be as follows:

the Dcm has sent a positive or negative response unequal to NRC 0x78 by receiving the Dcm_TpTxConfirmation connected to the response given by the DSL submodule

the Dcm has processed the service with SPRMIB=true and the positive response was suppressed

in case of functional addressing, the Dcm has processed the service and the negative response was suppressed.

Diagnostic Service Dispatcher (DSD)

Introduction

The DSD submodule is responsible to check the validity of an incoming diagnostic request (Verification of Diagnostic Session/Security Access levels/Application permission) and keeps track of the progress of a service request execution.

[SWS_Dcm_00178]

[ ]

The DSD submodule shall only process valid requests and shall reject invalid ones.

Use cases

The following use cases are relevant and are described in detail in the following:

Receive a request message and transmit a positive response message

Receive a request message and suppress a positive response

Receive a request message and suppress a negative response

Receive a request message and transmit a negative response message

Send a positive response message without corresponding request

Segmented Responses

Receive a request message and transmit a positive response message

This is the standard use case of normal communication ("ping-pong"). The server receives a diagnostic request message. The DSD submodule ensures the validity of the request message. In this use case, the request is valid and the response will be positive. The request will be forwarded to the appropriate data processor in the DSP submodule. When the data processor has finished all actions of data processing, it triggers the transmission of the response message by the DSD submodule.

If the data processor processes the service immediately as part of the request indication function, the data processor can trigger the transmission inside this indication function ("synchronous"). If the processing takes a longer time (e. g. waiting on EEPROM driver), the data processor defers some processing ("asynchronous"). The response pending mechanism is covered by the DSL submodule. The data processor triggers the transmission explicitly, but from within the data processor’s context.

As soon as a request message is received, the corresponding DcmPduId is blocked by the DSL submodule (see [SWS_Dcm_00241]). During the processing of this request, no other request of the same protocol type (e.g. an enhanced session can be ended by a OBD session) can be received, until the corresponding response message is sent and the DcmPduId is released again.

Receive a request message and suppress a positive response

This is a sub-use-case of the previous one. Within the UDS protocol it is possible to suppress the positive response by setting a special bit in the request message (see [SWS_Dcm_00200]). This special suppression handling is completely performed within the DSD submodule.

Receive a request message and suppress a negative response

In case of functional addressing the DSD submodule shall suppress the negative response for NRC 0x11, 0x12, 0x31, 0x7E and 0x7F (see [SWS_Dcm_00001]).

Receive a request message and transmit a negative response message

There are a many different reasons why a request message is rejected and a negative response is to be sent. If a diagnostic request is not valid or if a request may not be executed in the current session, the DSD submodule will reject the processing and a negative response will be returned.

But there are even many reasons to reject the execution of a well-formed request message, e.g. if the ECU or system state does not allow the execution. In this case, the DSP submodule will trigger a negative response including an NRC supplying additional information why this request was rejected.

In case of a request composed of several parameters (e.g. a UDS Service ReadDataByIdentifier (0x22) request with more than one identifier to read), each parameter is treated separately. And each of these parameters can return an error. This kind of request returns a positive response if at least one of the parameters was processed successfully.

[SWS_Dcm_00827]

[ ]

The DSD sub-module shall check the received diagnostic request in the order given by ISO14229-1 [1]. If one of the computations failed the Dcm shall stop the execution of the NRC check sequence then stop or do not start the execution of the received diagnostic request and finally transmit the NRC for which the computation failed.

Send a positive response message without corresponding request

There are two services within the UDS protocol, where multiple responses are sent for only one request. In general, one service is used to enable (and disable) an event- or time-triggered transmission of another service, which again is sent by the ECU without a corresponding request (see ISO14229-1 [1]). These services are:

UDS Service ReadDataByPeriodicIdentifier (0x2A). This service allows the client to request the periodic transmission of data record values from the server identified by one or more periodicDataIdentifiers.

Type 2 = UUDT message on a separate DcmTxPduId.

ResponseOnEvent (0x86). This service requests a server to start or stop transmission of responses on a specified event.

Type 1 = USDT messages on the DcmTxPduId already used for normal diagnostic responses,

Type 2 = USDT messages on separate DcmTxPduId.

For Type 1, the outgoing messages must be synchronized with "normal outgoing messages", which have a higher priority.

This handling is especially controlled by the DSL submodule. However, the DSD submodule also provides the possibility to generate a response without a corresponding request.

Segmented Responses (paged-buffer)

Within the diagnostic protocol, some services allow to exchange a significant amount of data, e.g. UDS Service ReadDTCInformation (0x19) and UDS Service TransferData (0x36).

In the conventional approach, the ECU internal buffer must be large enough to keep the longest data message which is to be exchanged (worst-case) and the complete buffer is filled before the transmission is started.

RAM memory in an ECU often is a critical resource, especially in smaller micros. In a more memory-saving approach, the buffer is filled only partly, transmitted partly and then refilled partly - and so on. This paging mechanism requires only a significantly reduced amount of memory, but demands a well-defined reaction time for buffer refilling.

The user can decide whether to use the "linear buffer" or paged-buffer for diagnostics.

Interaction of the DSD with other modules

The DSD submodule is called by the DSL submodule when receiving a diagnostic message and performs the following operations:

delegates processing of request to the DSP submodule or external modules outside the Dcm

keeps track of request processing (Return the status on <Module>_<DiagnosticService>() and <Module>_<DiagnosticService>_<SubService>() APIs call or "Service Interpreter calls")

transmits the response of the Application to the DSL submodule (Transmit functionality)

Interaction of the DSD with the DSL main functionality

Table 7.1: Interaction between the DSD submodule and the DSL submodule

Interaction of the DSD with the DSP

Table 7.2: Interaction of the DSD with the DSP

Functional Description of the DSD

Support checking the diagnostic service identifier and adapting the diagnostic message

The DSD submodule shall be triggered by the DSL submodule if a new diagnostic message is recognized. The DSD submodule will start processing by analyzing the diagnostic service identifier contained in the received diagnostic message.

[SWS_Dcm_00084]

[ ]

If configured (configuration parameter DcmRespondAllRequest=FALSE), if the Dcm module receives a diagnostic request that contains a service ID that is in the range from 0x40 to 0x7F or in the range from 0xC0 to 0xFF, the Dcm shall not respond to such a request.

This range corresponds to the diagnostic response identifier.

[SWS_Dcm_00192]

[ ]

The DSD submodule shall analyze the (incoming) diagnostic message for the diagnostic service identifier (based on first byte of the diagnostic message) and shall check the supported services with the newly received diagnostic service identifier.

[SWS_Dcm_00193]

[ ]

During this check, the DSD submodule shall search the newly received diagnostic service identifier in the "Service Identifier Table".

For performance reasons it might be necessary that the support check is done with a "lookup table" functionality. In this "Service Identifier Table" all supported Service IDs of the ECU are predefined.

[SWS_Dcm_00195]

[ ]

The DSL submodule shall provide the current "Service Identifier Table"

Rationale for [SWS_Dcm_00195]: The "Service Identifier Table" and the information about the supported services will be generated out of the configuration. More than one Service Identifier Table can be configured for selection. At one time only one Service Identifier Table can be active.

[SWS_Dcm_00196]

[ ]

For the check, the DSD submodule shall scan the active "Service Identifier Table" for a newly received diagnostic service identifier. If this service identifier is supported and if the configuration parameter DcmDsdSidTabFnc (see ECUC_Dcm_00777) is not empty, the DSD submodule shall call the configured service interface (<Module>_<DiagnosticService>). If the configuration parameter is empty, the Dcm shall call the internally implemented service interface.

The diagnostic service identifier is not supported when it is not included in the "Service Identifier Table".

[SWS_Dcm_00197]

[ ]

If the newly received diagnostic service identifier is not supported, the DSD submodule shall transmit a negative response with NRC 0x11 (Service not supported) to the DSL submodule.

[SWS_Dcm_00198]

[ ]

The DSD submodule shall store the newly received diagnostic service identifier for later use.

For example: WriteDataByIdentifier (for writing VIN number):

A new diagnostic message is received by the DSL submodule. (Diagnostic Message WriteDataByIdentifier = 0x2E, 0xF1, 0x90, 0x57, 0x30, 0x4C, 0x30, 0x30, 0x30, 0x30, 0x34, 0x33, 0x4D, 0x42, 0x35, 0x34, 0x31, 0x33, 0x32, 0x36)

The DSL submodule indicates a new diagnostic message with the "Data Indication" functionality to the DSD submodule. In the diagnostic message buffer the diagnostic message is stored (buffer = 0x2E,0xF1,0x90,..).

The DSD submodule executes a check of the supported services with the determined service identifier (first byte of buffer 0x2E) on the incoming diagnostic message.

The incoming diagnostic message is stored in the Dcm variable Dcm_MsgContextType.

[SWS_Dcm_CONSTR_06047]

[ ]

Id of the Service identifier configured in DcmDsdSidTabServiceId shall be unique within one DcmDsdServiceTable.

[SWS_Dcm_00732]

[ ]

For the first call of <Module>_<DiagnosticService> the opStatus shall be set to DCM_INITIAL.

[SWS_Dcm_00733]

[ ]

The Dcm shall not accept further requests (on same or lower priority) while <Module>_<DiagnosticService>() returns DCM_E_PENDING. Dcminternal timeout handling (based on RCR-RP limitation) may lead to a cancellation of the external diagnostic service processing.

[SWS_Dcm_00735]

[ ]

In case of cancellation the API <Module>_<DiagnosticService> is called again with the parameter opStatus set to DCM_CANCEL.

Handling of "suppressPosRspMsgIndicationBit"

The "suppressPosRspMsgIndicationBit" is part of the subfunction parameter structure (Bit 7 based on second byte of the diagnostic message, see ISO14229-1 [1] Section 6.5: Server response implementation rules).

[SWS_Dcm_00200]

[RS_Diag_04020]

If the "suppressPosRspMsgIndicationBit" is TRUE, the DSD submodule shall NOT send a positive response message.

[SWS_Dcm_00201]

[ ]

The DSD submodule shall remove the "suppressPosRspMsgIndicationBit" (by masking the Bit) from the diagnostic message.

[SWS_Dcm_00202]

[ ]

The Dcm module shall transport the information on a suppression of a positive response being active (between the layers) via the parameter Dcm_MsgContextType.

[SWS_Dcm_00203]

[ ]

In case of responsePending the Dcm module shall clear the "suppressPosRspMsgIndicationBit."

Rationale for [SWS_Dcm_00203]: In the described case the final response (negative/- positive) is required.

[SWS_Dcm_00204]

[ ]

The Dcm module shall only perform the "suppressPosRspMsgIndicationBit" handling when the configuration parameter DcmDsdSidTabSubfuncAvail is set for the newly received service identifier

Note:

The "suppressPosRspMsgIndicationBit" handling needs to be considered independent of the processing order in the request (like for RoutineControl service).

Rationale for [SWS_Dcm_00204]: The "suppressPosRspMsgIndicationBit" is only available if a service has a subfunction.

Verification functionality

Prior of execution of a received diagnostic service, the DSD performs a set of verifications. The DSD will only accept a service, if all verifications are successfully passed.

DSD verifications prior of service execution

[SWS_Dcm_01535]

[RS_Diag_04230]

[RS_Diag_04005]

[RS_Diag_04006]

The Dcm shall only accept a diagnostic request, if the following verifications have been passed in the following order:

Verification of Manufacturer permission (Call of the manufacturer interface indication operation)

Verification of the SID

Verification of the service access control on the current authentication state

Verification of the Diagnostic Session

Verification of the Service Security Access levels

Verification of the Supplier permission (Call of the Supplier interface indication operation)

Verification of the Mode rules for service IDs.

[SWS_Dcm_01474]

[RS_Diag_04235]

In case the DSD generates a NRC, the Dcm shall only call XXX_Confirmation.

This means that the Dcm will not call DspInternal_DcmConfirmation().

Verification of the diagnostic service access rights

The UDS service Authentication (0x29) is used to change the authentication state of a diagnostic connection and to provide the access rights. Depending on the reached role and provided white list a dynamic set of diagnostic services is available for the tester on that connection. The DSD submodule verifies on service ID (SID) and sub-function (SF) level, if a service can be executed or not.

Authentication on UDS services only

[SWS_Dcm_01536]

[RS_Diag_04230]

The Dcm shall only verify the authentication for UDS services. A UDS service has a service ID within the range of 0x10 and 0xFF.

OBD services are explicitly excluded from authentication checks. By legislation the OBD services need to be always available, independent from active authentication state. If WWH-OBD is used the system engineer must ensure that these services are always accessible.

Verifying access rights

[SWS_Dcm_01537]

[RS_Diag_04230]

The Dcm shall only verify and check the configured access rights of a diagnostic service, if the container DcmDspAuthentication is configured.

If no DcmDspAuthentication is configured, the Dcm will process all diagnostic services as if the current connection would grant access to execute the current processed service. Checking the access rights for diagnostic services is done at different levels of the service structure. The use of diagnostic service access rights introduces means to allow or to refuse a diagnostic service due to current roles and authentication states. Some services shall always be allowed to be executed, like the service 0x29 (Authentication) to set the current tester access rights. This service and other OEM or supplier specific services should have granted access independent from the authentication state. To realize this, the Dcm uses a default role that is used in all deauthenticated states. In that state, all role based verifications are done as in authenticated state. The active role is provided by the configuration.

Access rights for services in deauthenticated state

[SWS_Dcm_01538]

[RS_Diag_04230]

If the current connection is in deauthenticated state, the Dcm shall use the role configured by DcmDspAuthenticationDeauthenticatedRoleRef as current role for all role based access verification checks.

Definition of allowed service execution

[SWS_Dcm_01539]

[RS_Diag_04233]

The Dcm shall allow the service execution, if a role verification was successful or the service is allowed by the white list.

Diagnostic service execution rights verification

[SWS_Dcm_01540]

[RS_Diag_04233]

The Dcm shall check if a service execution is permitted in the current authentication check or not. The Dcm shall perform the following checks in the given order below. If a check grants access to a service, the remaining checks are skipped:

Checks on service ID level

Checks on service ID and sub-function level

Checks for services with one or multiple DIDs

Check on dynamically defined DIDs

Checks on service 0x31 per sub-function

Checks on service 0x19 parameter MemorySelection

Service ID authentication check for UDS service requests

[SWS_Dcm_01541]

[RS_Diag_04233]

Upon processing a diagnostic service, the Dcm shall grant access to the diagnostic service if:

for that service a service role is configured via DcmDsdServiceRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has one entry for a SID (1-byte element) which matches that service.

Service with sub-function authentication check for UDS service requests

[SWS_Dcm_01542]

[RS_Diag_04230]

Upon processing a diagnostic service with sub-function, the Dcm shall grant access to the diagnostic service if:

for that service and subfunction a subservice service role is configured via DcmDsdSubServiceRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has one entry for a SID with sub-function (2-byte element) that matches that service and sub-function.

White list verification for services with 3 and 4 bytes

[SWS_Dcm_01562]

[RS_Diag_04233]

For 3 and 4 bytes white list for services entries, the Dcm shall verify on the full length of the configured white list service element. The service is granted access if the first bytes of the received request match the entire white list entry.

Verification of byte 3 and 4 within the Dsd is beyond the scope of a typical Dsd operation. It provides means to extend the capabilities of white list service verifications and gives means to adapt to legacy authentication solutions.

Response behavior of services without access rights

[SWS_Dcm_01544]

[RS_Diag_04230]

If the service execution verification fails due to a failed check in scope of [SWS_Dcm_01540], the Dcm shall send a NRC 0x34 authenticationRequired and stop the service processing.

Verification of the Diagnostic Session

The UDS Service DiagnosticSessionControl (0x10) is used to enable different diagnostic sessions in the ECU (e.g. Default session, Extended session). A diagnostic session enables a specific set of diagnostic services and/or functionality in the ECU. It furthermore enables a protocol-depending data set of timing parameters applicable to the started session.

On receiving a service request, the DSD module will obtain the current Diagnostic Session with Dcm_GetSesCtrlType and will verify whether the execution of the requested service (NOT the UDS Service DiagnosticSessionControl (0x10)) and subservice is allowed in the current diagnostic session or not.

Note that the handling of the UDS Service DiagnosticSessionControl (0x10) itself is not part of the DSD submodule.

[SWS_Dcm_00211]

[ ]

If the newly received diagnostic service is not allowed in the current Diagnostic Session (according to the configuration parameter DcmDsdSidTabSessionLevelRef), the DSD submodule shall transmit a negative response with NRC 0x7F (serviceNotSupportedInActiveSession) to the DSL submodule.

[SWS_Dcm_00616]

[ ]

If the newly received diagnostic service is allowed in the current Diagnostic Session ( see [SWS_Dcm_00211]), but the requested subservice is not allowed in the current Diagnostic Session (according to the configuration parameter DcmDsdSubServiceSessionLevelRef), the DSD submodule shall transmit a negative response with NRC 0x7E (subFunctionNotSupportedInActiveSession) to the DSL submodule.

Verification of the Service Security Access levels

The purpose of the Security Access level handling is to provide a possibility to access data and/or diagnostic services, which have restricted access for security, emissions, or safety reasons. The DSD submodule shall perform this handling with the UDS Service SecurityAccess (0x27). The DSD submodule will perform a verification whether the execution of the requested service (NOT the UDS Service SecurityAccess (0x27)) is allowed in the current Security level by asking for the current security level, using the DSL function Dcm_GetSecurityLevel.

The management of the security level is not part of the DSD submodule.

Note:

For some use cases (e.g. UDS Service ReadDataByIdentifier (0x22), where some DataIdentifier can be secure) it will be necessary for the Application to call also the function Dcm_GetSecurityLevel.

[SWS_Dcm_00217]

[ ]

If the newly received diagnostic service is not allowed in the current Security level (according to the configuration parameter DcmDsdSidTabSecurityLevelRef), the DSD submodule shall transmit a negative response with NRC 0x33 (Security access denied) to the DSL submodule.

[SWS_Dcm_00617]

[ ]

If the newly received diagnostic service is allowed in the current Security level ( see [SWS_Dcm_00217]), but the requested subservice is not allowed in the current Security level (according to the configuration parameter DcmDsdSubServiceSecurityLevelRef), the DSD submodule shall transmit a negative response with NRC 0x33 (Security access denied) to the DSL submodule.

Verification of the Service mode dependencies

[SWS_Dcm_00773]

[ ]

If the newly received diagnostic service is not allowed in the current mode condition (according to the configuration parameter DcmDsdSidTabModeRuleRef), the DSD submodule shall transmit the calculated negative response of the referenced DcmModeRule to the DSL submodule.

[SWS_Dcm_00774]

[ ]

If the newly received diagnostic service is allowed in the current mode condition [SWS_Dcm_00773], but the requested subservice is not allowed in the current mode condition (according to the configuration parameter DcmDsdSubServiceModeRuleRef), the DSD submodule shall transmit the calculated negative response of the referenced DcmModeRule to the DSL submodule.

Check format and subfunction support

The DSD submodule checks whether a specific subfunction is supported before executing the requested command.

General sub-function supported NRC check

[SWS_Dcm_00273]

[ ]

The DSD shall send the negative response NRC 0x12 (sub-functionNotSupported ), if for the processed service no configured DcmDsdSubService exists with the DcmDsdSubServiceId of the processed service. This NRC check shall not be done for UDS Service 0x31 (RoutineControl).

The DSD submodule will check for the minimum message length before executing the requested command.

[SWS_Dcm_00696]

[ ]

The DSD submodule shall trigger a negative response with NRC 0x13 (Incorrect message length or invalid format), if the length of the request is inferior to the minimum length of the request.

[SWS_Dcm_01411]

[ ]

If DcmDsdSubService is configured for a DcmDsdService, the Dcm shall support the sub-function configured in DcmDsdSubServiceId with SPRMIB set to 0 or 1.

Verification of the Manufacturer Application environment/permission

The purpose of this functionality is that, just after receiving the diagnostic request, the Manufacturer Application is requested to check permission/environment.

E.g. in after-run ECU state, it might be not allowed to process OBD requests.

[SWS_Dcm_00218]

[ ]

If container DcmDsdServiceRequestManufacturerNotification exists, the DSD submodule shall call the operation Xxx_Indication on all configured ServiceRequestIndication ports (see configuration parameter DcmDsdServiceRequestManufacturerNotification).

[SWS_Dcm_00462]

[ ]

If at least a single Xxx_Indication function called according to [SWS_Dcm_00218] returns E_REQUEST_NOT_ACCEPTED, the DSD submodule shall give no response.

[SWS_Dcm_01172]

[ ]

In case of [SWS_Dcm_00462], the DSD shall only call Xxx_Confirmation but not DspInternal_DcmConfirmation.

[SWS_Dcm_00463]

[ ]

If at least a single Xxx_Indication function called according to [SWS_Dcm_00218] has returned E_NOT_OK and no function has returned E_REQUEST_NOT_ACCEPTED, the DSD submodule shall trigger a negative response with NRC from the ErrorCode parameter.

[SWS_Dcm_01321]

[RS_Diag_04011]

If more than one Xxx_Indication function called, according to [SWS_Dcm_00218], has returned E_NOT_OK and no function has returned E_REQUEST_NOT_ACCEPTED, the DSD submodule shall trigger a negative response using the ErrorCode parameter from the first Xxx_Indication returning E_NOT_OK.

Verification of the Supplier Application environment/permission

The purpose of this functionality is that, right before processing the diagnostic message, the Supplier Application is requested to check permission/environment.

E.g. in after-run ECU state, it might be not allowed to process OBD requests.

[SWS_Dcm_00516]

[ ]

If container DcmDsdServiceRequestSupplierNotification exists, the DSD submodule shall call the operation Xxx_Indication on all configured ServiceRequestIndication ports (see configuration parameter DcmDsdServiceRequestSupplierNotification).

[SWS_Dcm_00517]

[ ]

If at least a single Xxx_Indication function called according to [SWS_Dcm_00516] returns E_REQUEST_NOT_ACCEPTED, the DSD submodule shall give no response.

[SWS_Dcm_00518]

[ ]

If at least a single Xxx_Indication function called according to [SWS_Dcm_00516] has returned E_NOT_OK and no function has returned E_REQUEST_NOT_ACCEPTED, the DSD submodule shall trigger a negative response with NRC from the ErrorCode parameter.

[SWS_Dcm_01322]

[RS_Diag_04011]

If more than one Xxx_Indication function called, according to [SWS_Dcm_00516], has returned E_NOT_OK and no function has returned E_REQUEST_NOT_ACCEPTED, the DSD submodule shall trigger a negative response using the ErrorCode parameter from the first Xxx_Indication returning E_NOT_OK.

Distribution of diagnostic message to DSP submodule

[SWS_Dcm_00221]

[ ]

The DSD submodule shall search for the executable functionality of the DSP submodule for newly received diagnostic service identifier and shall call the corresponding DSP service interpreter.

Assemble positive or negative response

[SWS_Dcm_00222]

[ ]

When the DSP submodule has finished the execution of the requested Diagnostic Service the DSD submodule shall assemble the response.

The execution of the DSP service interpreter can have the results:

positive Result or

negative Result.

Following possible Responses can be assembled:

positive Response,

negative Response, or

no Response (in the case of suppression of responses).

Positive Response

[SWS_Dcm_00223]

[ ]

The DSD submodule shall add the response service identifier and the response data stream (returned by the Application) in the parameter "Dcm_MsgContextType".

[SWS_Dcm_00224]

[ ]

The DSD submodule shall therefore transfer the Dcm_MsgContextType into a (response) buffer and shall add the service identifier at the first byte of the buffer.

[SWS_Dcm_00225]

[ ]

The DSD submodule shall execute the "Initiate transmission" functionality in the next execution step.

Negative Response

The DSP submodule can trigger the transmission of a negative response with a specific NRC to the DSD submodule. For the allowed NRC of the executed Service ID please refer to the specification of the service in ISO14229-1 [1] (see Section 4.2.4 Response code parameter definition Table 12) and ISO15031-5 [2]. The DSP and the Application have to take care of the correct use of NRC of the executed Service ID.

[SWS_Dcm_00228]

[ ]

The DSD submodule shall handle all NRCs supported from the Application and defined in Dcm_NegativeResponseCodeType.

Suppression of response

[SWS_Dcm_00231]

[ ]

In the case that the "suppressPosRspMsgIndicationBit" is indicated in the functionality "Handling of suppressPosRspMsgIndicationBit" (stored in the Variable Dcm_MsgContextType (Element: Dcm_MsgAddInfo)), the DSD submodule shall activate the suppression of Positive Responses.

[SWS_Dcm_00001]

[RS_Diag_04020]

In the case of a Negative Result of the execution and active Functional Addressing the DSD submodule shall activate the suppression of the following Negative Responses:

NRC 0x11 (Service not supported),

NRC 0x12 (SubFunction not supported),

NRC 0x31 (Request out of range),

NRC 0x7E (Subfunction not supported in active session),

NRC 0x7F (Service not supported in active session)

Initiate transmission

[SWS_Dcm_00232]

[ ]

The DSD submodule shall forward the diagnostic (response) message (positive or negative response) to the DSL submodule.

[SWS_Dcm_00237]

[ ]

The DSL submodule shall forward the diagnostic (response) message (positive or negative response) further to the PduR module by executing a DSL transmit functionality.

The DSL submodule will receive a confirmation by the PduR module upon forwarding the data.

[SWS_Dcm_00235]

[ ]

The DSL submodule shall forward the received confirmation from the PduR module to the DSD submodule.

[SWS_Dcm_00236]

[ ]

The DSD submodule shall forward the confirmation via the internal function DspInternal_DcmConfirmation() to the DSP submodule.

[SWS_Dcm_00238]

[ ]

In the case that no diagnostic (response) message shall be sent (Suppression of Responses) the DSL submodule shall not transmit any response.

In this case no Data Confirmation is sent from the DSL submodule to the DSD submodule but the DSD submodule will still call internal function DspInternal_DcmConfirmation().

[SWS_Dcm_00240]

[ ]

In case the request has been fully processed by the Dcm, The DSD submodule shall finish the processing of one Diagnostic Message of the Diagnostic Service Dispatcher by calling DspInternal_DcmConfirmation().

Rationale for [SWS_Dcm_00240]: The DSP submodule is waiting for the execution of the DspInternal_DcmConfirmation() functionality. So it has to be sent, also when no Data Confirmation is provided. Altogether this means that in any of the following cases:

Positive Response,

Negative Response,

Suppressed Positive Response, and

Suppressed Negative Response

The DSD submodule will finish by calling DspInternal_DcmConfirmation() (refer to 8.10.3 DspInternal_DcmConfirmation).

[SWS_Dcm_00741]

[ ]

The DSD submodule shall call the operation Xxx_Confirmation() on all ports using the ServiceRequestNotification interface (see configuration parameter DcmDsdServiceRequestManufacturerNotification and DcmDsdServiceRequestSupplierNotification)

[SWS_Dcm_00742]

[ ]

The call of Xxx_Confirmation() shall be done right after the call of DspInternal_DcmConfirmation()

[SWS_Dcm_00677]

[ ]

If the operation Indication() returns value E_REQUEST_NOT_ACCEPTED, the Dcm module shall not send any diagnostic response and shall end the current diagnostic request management.

[SWS_Dcm_00678]

[ ]

If the operation Indication() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC value equal to ErrorCode parameter value.

Diagnostic Service Processing (DSP)

General

When receiving a function call from the DSD submodule requiring the DSP submodule to process a diagnostic service request, the DSP always carries out following basic process steps:

analyze the received request message,

check format and whether the addressed subfunction is supported,

acquire data or execute the required function call on the DEM, SW-Cs or other BSW modules

assemble the response

The following sections are some general clarifications.

Check format and subfunction support

The DSP submodule will check for appropriate message length and structure before executing the requested command.

[SWS_Dcm_00272]

[ ]

The DSP submodule shall trigger a negative response with NRC 0x13 (Incorrect message length or invalid format), when the analysis of the request message results in formatting or length failure.

Note:

It is up to the implementation in which detail the format check might be executed and depends on the level of detail the diagnostic data description provides at compile time.

Assemble response

[SWS_Dcm_00039]

[ ]

The DSP submodule shall assemble the response message excluding response service identifier and determine the response message length.

[SWS_Dcm_00038]

[ ]

If the paged-buffer mechanism is used, the DSP submodule shall determine the overall response length before any data is passed to the DSD submodule or the DSL submodule respectively.

Requirement [SWS_Dcm_00038] is needed because of segmented diagnostic data transmission on CAN using ISO15765-2 [15], which requires the provision of the overall length of the complete data stream in the very first CAN frame of the respective data transmission (please refer to Section 7.4.4.8 for details about the paged-buffer mechanism).

Negative Response Codes handling

[SWS_Dcm_00271]

[ ]

Unless another particular NRC is specified,the DSP submodule shall trigger a negative response with NRC 0x10 (generalReject), when the API calls made to execute the service do not return OK.

Accepted range of Dcm_NegativeResponseCodeType for negative responses

[SWS_Dcm_01414]

[ ]

If the Dcm calls an external application by any of the APIs having the out parameter Dcm_NegativeResponseCodeType ErrorCode, the Dcm shall accept only values in the range 0x01-0xFF in case the return value is E_NOT_OK.

Behavior on application returning unexpected return code

[SWS_Dcm_01415]

[ ]

If the Dcm calls an API with the out parameter Dcm_NegativeResponseCodeType ErrorCode and the application sets this parameter to DCM_POS_RESP and E_NOT_OK is returned, the Dcm shall report the runtime error DCM_E_INVALID_VALUE.

[SWS_Dcm_00275]

[ ]

The DSP submodule shall trigger a negative response with NRC 0x31 (Request out of range), when the analysis of the request message results in other unsupported message parameters.

Diagnostic mode declaration groups

[SWS_Dcm_00775]

[ ]

The Dcm shall act as a mode manager for the diagnostic modes:

DcmDiagnosticSessionControl (service 0x10)

DcmEcuReset (partly service 0x11)

DcmSecurityAccess (service 0x27)

DcmModeRapidPowerShutDown (partly service 0x11)

DcmCommunicationControl_<symbolic name of ComMChannelId>. (service 0x28)

DcmControlDTCSetting (service 0x85)

DcmResponseOnEvent_<RoeEventID> (service 0x86)

DcmAuthenticationState_<Symbolic Name of DcmDslMainConnection>

Note:

The RTE/SchM will prefix the names with "MODE_", wherefore the names do not include the MODE keyword.

[SWS_Dcm_01327]

[ ]

The Dcm shall define the ModeDeclarationGroupPrototype DcmSecurityAccess as provided-ModeGroup based on the following ModeDeclarationGroup:

ModeDeclarationGroup DcmSecurityAccess
{
{
DCM_SEC_LEV_LOCKED
DCM_SEC_LEV_1
...
DCM_SEC_LEV_63
}
initialMode = DCM_SEC_LEV_LOCKED
};

[SWS_Dcm_01328]

[ ]

ModeSwitchInterface SchM_Switch_<bsnp>_DcmSecurityAccess
{
isService = true;
SecLevel currentMode;
};

[SWS_Dcm_00806]

[ ]

The Dcm shall define the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl as provided-ModeGroup based on the ModeDeclarationGroup DcmDiagnosticSessionControl.

[SWS_Dcm_00777]

[ ]

The Dcm shall define the ModeDeclarationGroupPrototype DcmEcuReset as provided-ModeGroup in its Basic Software Module instance based on the ModeDeclarationGroup DcmEcuReset.

[SWS_Dcm_00807]

[ ]

The Dcm shall define the ModeDeclarationGroupPrototype DcmModeRapidPowerShutDown as provided-ModeGroup in its Basic Software Module instance based on the ModeDeclarationGroup DcmModeRapidPowerShutDown.

[SWS_Dcm_00780]

[ ]

The Dcm shall define for each network which is considered in the CommunicationControl service a separate ModeDeclarationGroupPrototype DcmCommunicationControl_<symbolic name of ComMChannelId> as providedModeGroup in its Basic Software Module instance based on the ModeDeclarationGroup DcmCommunicationControl.

[SWS_Dcm_00781]

[ ]

The Dcm shall define the ModeDeclarationGroupPrototype DcmControlDTCSetting as provided-ModeGroup in its Basic Software Module instance based on the ModeDeclarationGroup DcmControlDTCSetting.

[SWS_Dcm_00933]

[ ]

The Dcm shall define for each RoeEvent a separate ModeDeclarationGroupPrototype DcmResponseOnEvent_<Symbolic name of RoeEventId> as provided-ModeGroup in its Basic Software Module instance based on the ModeDeclarationGroup DcmResponseOnEvent.

The Dcm provides a state machine for each RoeEvent. The state for a RoeEvent is needed by SWC to activate event reporting or report the Roe status to a Did. Therefore the Dcm provides for each state of each RoeEvent a ModeDeclarationGroupPrototype which reports the current state of the state machine as mode.

[SWS_Dcm_00934]

[ ]

The ModeDeclarationGroupPrototype shall represent the current state of the ROE state machine for this RoeEvent.

Environmental condition dependent execution

The execution of a diagnostic service or the acceptance of certificates can be restricted to a mode condition. This enables the Dcm to formalize environmental checks. For diagnostic service processing, a further check (see [SWS_Dcm_00773] and [SWS_Dcm_00774]) can be configured to the Dcm. This is like session and security checks. The referenced mode rule is arbitrating on to several mode declarations of a mode declaration groups in which the request can be processed. Otherwise a configurable NRC (see [SWS_Dcm_00812]) is responded. The same mode rule checks can be applied on certificate validation. Certificates can be restricted to certain vehicle properties, such as VIN or a certain version number. Only if all the conditions are valid, the certificate is accepted by the Dcm.

[SWS_Dcm_00808]

[ ]

The DcmModeRule shall evaluate all referenced DcmModeConditions and/or nested DcmModeRules either by a logical AND in case DcmLogicalOperator is set to DCM_AND or by a logical OR in case the DcmLogicalOperator is set to DCM_OR. In case only a single DcmModeCondition or DcmModeRule is referenced the DcmLogicalOperator shall not be present and therefore not be used.

[SWS_Dcm_CONSTR_06028]

[ ]

DcmModeCondition shall either have a DcmBswModeRef or a DcmSwcModeRef or a DcmSwcSRDataElementRef as external reference.

[SWS_Dcm_00810]

[ ]

The DcmSwcModeRef and DcmBswModeRef of DcmModeConditions shall evaluate if the referenced Mode-Declaration is set in case of DcmConditionType is set to DCM_EQUALS or is not set in case of DcmConditionType is set to DCM_EQUALS_NOT.

Mode condition evaluation

[SWS_Dcm_01119]

[ ]

For each mode condition, the Dcm shall compare a compare value with a S/R data element. The compare value is provided by DcmSwcSRDataElementValueRef or DcmModeConditionConnectionCertificateCompareElementRef and the S/R Element is by DcmSwcSRDataElementRef. The mode condition is evaluated to true if the S/R data element value is:

equal to the compare value in case of DcmConditionType is set to DCM_EQUALS

unequal to the compare value in case of DcmConditionType is set to DCM_EQUALS_NOT

greater than the compare value in case of DcmConditionType is set to DCM_GREATER_THAN

greater or equal than the compare value in case of DcmConditionType is set to DCM_GREATER_OR_EQUAL

less than the compare value in case of DcmConditionType is set to DCM_LESS_THAN

less or equal than the compare value in case of DcmConditionType is set to DCM_LESS_OR_EQUAL.

[SWS_Dcm_CONSTR_06029]

[ ]

The values DCM_GREATER_THAN, DCM_GREATER_OR_EQUAL, DCM_LESS_OR_EQUAL and DCM_LESS_THAN shall not used with a Mode reference (DcmBswModeRef or DcmSwcModeRef) .

Note:

The current mode of the referenced ModeDeclarationGroupPrototypes could be read by either the API SchM_Mode (in case of DcmBswModeRef) or by the API Rte_Mode (in case of DcmSwcModeRef).

[SWS_Dcm_00811]

[ ]

In case multiple DcmModeConditions are referenced within a DcmModeRule they shall be evaluated in order of the index attributes of the EcucReferenceValues for DcmArgumentRef.

Note:

This implies the priority of NRCs

[SWS_Dcm_00782]

[ ]

If a DcmModeRule is not referenced from the DcmDspAuthenticationConnection, the Dcm shall use the optional parameter DcmModeRuleNrcValue as NegativeResponseCode in case the mode rule is evaluated to false.

Mode rules for DcmDspAuthenticationConnection are not part of the NRC evaluation.

[SWS_Dcm_00812]

[ ]

In case a nested DcmModeRule contains also a DcmModeRuleNrcValue parameter, this NRC shall be used prior the higher-level NRC.

[SWS_Dcm_00813]

[ ]

In case DcmLogicalOperator is set to DCM_AND, the first failed DcmModeRule with an explicit configured NRC (DcmModeRuleNrcValue) shall be used to define the NRC for the response message.

[SWS_Dcm_00814]

[ ]

In case DcmLogicalOperator is set to DCM_OR, the last failed DcmModeRule with an explicit configured NRC (DcmModeRuleNrcValue) shall be used to define the NRC for the response message.

Note:

The difference in the AND and OR logical operation is to allow an optimized implementation.

[SWS_Dcm_00815]

[ ]

In case the complete evaluation result in no specific NRC the NRC 0x22 (ConditionsNotCorrect) shall be used.

[SWS_Dcm_00942]

[ ]

The Dcm shall create for commonly used ModeDeclarationGroupPrototype of each DcmSwcModeRef of DcmModeConditions a required mode switch port referencing this ModeDeclarationGroupPrototype. The name pattern of this port prototype shall be DcmModeUser_<ModeDeclarationGroupPrototype>" in case the ModeDeclarationGroupPrototype shortname is unique. Otherwise the name pattern is implementation specific, except the required prefix "DcmModeUser_".

Note:

ModeDeclarationGroupPrototypes are not necessarily unique, wherefore the exception is required to avoid name clashes in the Dcm Service-SWC.

Examples on using mode dependent request execution:

General assumptions:

DcmModeRule1 consists of DcmModeCondition1, DcmModeRule2 and DcmModeRule3

DcmModeRule1 defines NRC 0x22

DcmModeRule2 and DcmModeRule3 do not have any sub-rules

DcmModeRule2 defines NRC 0x72

DcmModeRule3 does not define a NRC value

Example 1:

DcmModeRule1 uses an OR combination (DcmModeCondition1 OR DcmModeRule2 OR DcmModeRule3)

DcmModeCondition1 is failing -> NRC 0x22 is returned

DcmModeRule2 is failing -> NRC 0x72 is returned

DcmModeRule3 is failing -> NRC 0x22 is returned

DcmModeCondition1, DcmModeRule2 and DcmModeRule3 are failing -> NRC 0x72 is returned

DcmModeCondition1 and DcmModeRule3 are failing -> NRC 0x22 is returned

Example 2:

DcmModeRule1 uses an AND combination (DcmModeCondition1 AND DcmModeRule2 AND DcmModeRule3)

DcmModeCondition1 is failing -> NRC 0x22 is returned

DcmModeRule2 is failing-> NRC 0x72 is returned

DcmModeRule3 is failing -> NRC 0x22 is returned

DcmModeCondition1, DcmModeRule2 and DcmModeRule3 are failing -> NRC 0x22 is returned

DcmModeCondition1 and DcmModeRule3 are failing -> NRC 0x22 is returned

DcmModeRule2 and DcmModeRule3 are failing -> NRC 0x72 is returned

Only one compare element

[SWS_Dcm_CONSTR_06089]

[RS_Diag_04232]

In one DcmModeCondition only one of the elements DcmSwcSRDataElementRef or DcmModeConditionCertificateCompareElementRef shall be configured.

Use of certificate compare elements

[SWS_Dcm_CONSTR_06090]

[ ]

The DcmModeConditionCertificateCompareElementRef is only allowed, if the parent DcmModeRule is referenced from a DcmDspAuthenticationConnection.

Sender/Receiver Communication

[SWS_Dcm_00964]

[ ]

If DcmDspDiagnosisScaling is present, the Dcm shall derive the CompuMethod from the DcmDspDiagnosisScaling container and add it to the DataType in their respective port interface for S/R port of DataServices_Data [SWS_Dcm_01035].

Passing SwDataDefProps properties from DEXT file to the Dcm Service SW-C

UseCase: Pass the SwDataDefProps details like CompuMethod, DataContraints and Units to the Dcm Service SW-C and make them there available per DID DataElement / per RoutineControl signal. Two alternative work flows are available.

DcmDspDiagnosticDataElementRef workflow

Figure 7.8: DcmDspDiagnosticDataElementRef Workflow

The feature of the DcmDspDiagnosticDataElementRef workflow is the use of a EcucForeignReference inside the generated EcuC values. While importing the DEXT information, a dedicated EcuC parameter is generated, which holds a EcucForeignReference named DcmDspDiagnosticDataElementRef to a DiagnosticDataElement in the DEXT file. This EcucForeignReference enables the access to all SwDataDefProps (BaseType, CompuMethod, DataConstr, etc.) of the corresponding DiagnosticDataElement. The container DcmDspAlternativeDiagnosticDataElement aggregates this EcucForeignReference. In the process step of generating the corresponding Service SWC all needed content will be copied directly based on the EcucForeignReference from DEXT to the Service SW-C. In this work flow the existence of the DEXT file while the generation of the Service SW-C is required.

[SWS_Dcm_CONSTR_06053]

[ ]

The aggregation of DcmDspTextTableMapping at DcmDspAlternativeDataType is only valid if the category of the CompuMethod of the DataType referenced by DcmDspAlternativeDataType.DcmApplicationDataType has category set to TEXTTABLE or SCALE_LINEAR_AND_TEXTTABLE.

DcmDspAlternativeDataType.DcmApplicationDataType workflow

Figure 7.9: DcmDspAlternativeDataType.DcmApplicationDataType Workflow

The feature of the DcmDspAlternativeDataType.DcmApplicationDataType workflow is that while importing the DEXT information beside the EcuC values also a SW-C fragment is generated. In this SW-C fragment all needed SwDataDefProps are directly copied from the DEXT file. Inside the generated EcuC values the EcuC parameter DcmDspAlternativeDataType.DcmApplicationDataType refers to the SWC fragment and enables the access to all SwDataDefProps (BaseType, CompuMethod, DataConstr, etc.). In the process step of generating the corresponding Service SW-C, all needed content will be included based on the reference from DcmDspAlternativeDataType.DcmApplicationDataType to the SW-C fragment. In this work flow the existence of the DEXT file while the generation of the Service SW-C is not required.

Asynchronous call behavior

[SWS_Dcm_01412]

[ ]

If a Dem function returns DEM_PENDING, the Dcm shall call this function again at a later point in time as long as DEM_PENDING is returned.

[SWS_Dcm_00120]

[ ]

If the number of negative responses for a requested diagnostic tasks (see [SWS_Dcm_00024]) reaches the value defined in the configuration parameter DcmDslDiagRespMaxNumRespPend, the Dcm module shall stop processing the active diagnostic request, inform the application or BSW (if this diagnostic task implies the call to a SW-C interface or a BSW interface) by setting OpStatus parameter, of active port interface, to DCM_CANCEL, report the runtime error DCM_E_INTERFACE_TIMEOUT and shall send a negative response with NRC 0x10 (General reject).

[SWS_Dcm_01184]

[ ]

The Dcm_SetProgConditions API shall be called again in the next Dcm main function cycle if previous return status was E_PENDING.

[SWS_Dcm_00760]

[ ]

The return of DCM_E_PENDING shall do a re-triggering (e.g. in the next MainFunction cycle).

[SWS_Dcm_01413]

[ ]

The return values of interfaces called with an OpStatus equal to DCM_CANCEL shall be ignored.

UDS Services

Diagnostic Request Validation

[SWS_Dcm_01622]

[RS_Diag_04196]

[RS_Diag_04203]

The Dcm shall execute the diagnostic request validation, negative response code (NRC) determination and processing according to ISO 14229-1 [1].

[SWS_Dcm_00442]

[ ]

The Dcm module shall implement the services of UDS according to Table 7.3.

Table 7.3: Support of UDS Services

General behavior using DEM interfaces

Fault memory related diagnostic services are by default processed directly within the Dcm. The Dcm uses the Dem module to clear, query, and read diagnostic fault codes, status, and related data. The option to process such a diagnostic via the callout of the DSD sub-module, e.g. DcmDsdSubServiceFnc for service 0x19, is considered an exceptional use case.

This chapter describes general rules, and how the Dcm interacts with the Dem to fulfill the task to process the fault memory related UDS services.

The UDS defined DTC status availability mask is managed by the Dem module and therefore not configured in the Dcm. When this mask is required the Dcm uses the Dem_GetDTCStatusAvailabilityMask API to read this information.

The UDS defined severity DTC severity availability mask is also managed by the Dem and therefore not configured by the Dcm. The Dcm uses Dem_GetDTCStatusAvailabilityMask to retrieve this mask information.

To ensure consistent event related data during the reading sequence, the Dcm module will lock the update of event related data during the read operation. The Dem provides Dem_DisableDTCRecordUpdate and Dem_EnableDTCRecordUpdate to temporarily stop updating the event memory. In particular, this happens during the use of the following Dem APIs.

Dem_SelectExtendedDataRecord()

Dem_GetSizeOfExtendedDataRecordSelection()

Dem_GetNextExtendedDataRecord()

Dem_SelectFreezeFrameData()

Dem_GetSizeOfFreezeFrameSelection()

Dem_GetNextFreezeFrameData()

Potentially time consuming API calls in the Dem are designed asynchronous so that the call can return and the caller can call again at a later time to retrieve the requested data. These APIs have DEM_PENDING as a possible return value. If this return value is detected, the Dcm will call again with the same parameters. The time of the next call is implementation specific, but mostly this will occur in the next Dcm_MainFunction. Repeated occurring DEM_PENDING as the return value from the Dem can result in ResponsePending NRC 0x78 sent by the Dcm.

Diagnostic Session Control (0x10) Service

UDS Service 0x10 allows an external tester to enable different diagnostic sessions in the server. A diagnostic session enables a specific set of diagnostic services and/or functionality in the server. The service request contains the parameter:

diagnosticSessionType

[SWS_Dcm_00250]

[RS_Diag_04006]

The Dcm module shall implement the UDS Service 0x10.

[SWS_Dcm_00307]

[ ]

When responding to UDS Service 0x10, if the requested subfunction value is not configured in the ECU (configuration parameter DcmDspSessionLevel), the DSP submodule shall trigger a negative response with NRC 0x12 (SubFunction not supported).

If the requested subfunction value is configured, the following steps are processed even if the requested session type is equal to the already running session type (see ISO14229-1 [1] Section 9.2).

[SWS_Dcm_00311]

[RS_Diag_04248]

The send confirmation function shall set the new diagnostic session type with DslInternal_SetSesCtrlType() and shall set the new timing parameters (P2ServerMax, P2ServerMax*) (see configuration parameters DcmDspSessionP2ServerMax and DcmDspSessionP2StarServerMax) and do the mode switch of the ModeDeclarationGroupPrototype DcmDiagnosticSessionControl by calling SchM_Switch_<bsnp>_DcmDiagnosticSessionControl() with the new diagnostic session type (see [SWS_Dcm_91019]).

[SWS_Dcm_00085]

[ ]

The DSP submodule shall manage internally a read access for the dataIdentifier 0xF186 (ActiveDiagnosticSessionDataIdentifier) defined in ISO14229-1 [1].

ECUReset (0x11) Service

UDS Service ECUReset (0x11) allows an external tester to request a server reset. The service request contains parameter:

resetType

[SWS_Dcm_00260]

[ ]

The Dcm module shall implement the UDS Service ECUReset (0x11).

[SWS_Dcm_00373]

[ ]

On reception of a request for UDS Service 0x11 with the sub functions other than enableRapidPowerShutDown (0x04) or disableRapidPowerShutDown (0x05), the Dcm module shall trigger the mode switch of ModeDeclarationGroupPrototype DcmEcuReset equal to the received resetType. After the mode switch is requested the Dcm shall trigger the start of the positive response message transmission. Sub function hardReset (0x01) to HARD Sub function keyOffOnReset (0x02) to KEYONOFF Sub function softReset (0x03) to SOFT

Note:

By this mode switch the Dcm informs the BswM to carry out necessary actions for the handling of this individual reset type. These actions can be configured within the BswM action list corresponding to the requested reset type. Here the integrator can also define if an ECU reset will finally be performed or not.

[SWS_Dcm_00594]

[ ]

On the transmit confirmation (call to Dcm_TpTxConfirmation) of the positive response, the Dcm module shall trigger the mode switch of ModeDeclarationGroupPrototype DcmEcuReset to the mode EXECUTE (via SchM_Switch_<bsnp>_DcmEcuReset(RTE_MODE_DcmEcuReset_EXECUTE)).

Note:

By this mode switch the Dcm requests the BswM to perform the final processing on the reset type according to the configured action list.

[SWS_Dcm_00818]

[ ]

On reception of a request for UDS Service 0x11 with the sub functions enableRapidPowerShutdown (0x04) or disableRapidPowerShutdown (0x05), the Dcm module shall trigger the mode switch of ModeDeclarationGroupPrototype DcmRapidPowerShutDown: Sub function enableRapidPowerShutDown (0x04) to ENABLE_RAPIDPOWERSHUTDOWN, Sub function disableRapidPowerShutDown (0x05) to DISABLE_RAPIDPOWERSHUTDOWN.

Note:

If EnableRapidPowerShutdown is enabled, the ECU should shorten its powerdown time.

[SWS_Dcm_00589]

[ ]

In case the parameter DcmDspPowerDownTime is present, the Dcm shall set the powerDownTime in positive response to sub-service enableRapidPowerShutDown with value set in DcmDspPowerDownTime.

[SWS_Dcm_00834]

[ ]

After sending the positive response of EcuReset (call of Dcm_TpTxConfirmation) the Dcm shall ignore all further requests during resetprocessing.

DcmDspEcuResetRow container configuration

[SWS_Dcm_CONSTR_06080]

[RS_Diag_04098]

One container DcmDspEcuResetRow shall be configured for each DcmDsdSubService (DcmDspEcuResetId matching to the DcmDsdSubServiceId) configured for the UDS service ECUReset (0x11) which does not have the corresponding DcmDsdSubServiceFnc parameter configured.

Clear Diagnostic Information (0x14) Service

UDS Service ClearDiagnosticInformation (0x14) requests an ECU to clear the error memory. The service request contains the parameter:

groupOfDTC

[SWS_Dcm_00247]

[ ]

The Dcm module shall implement UDS Service 0x14.

[SWS_Dcm_01263]

[RS_Diag_04058]

Upon reception of a UDS Service ClearDiagnosticInformation (0x14) request with parameter groupOfDTC, the Dcm module shall call the API Dem_SelectDTC() with the following parameter values:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

DTC: groupOfDTC from the service request

DTCFormat: DEM_DTC_FORMAT_UDS

DTCOrigin: DEM_DTC_ORIGIN_PRIMARY_MEMORY

[SWS_Dcm_01400]

[ ]

After call of Dem_SelectDTC() the Dcm shall call Dem_GetDTCSelectionResultForClearDTC() with the following parameter value:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef.

[SWS_Dcm_01265]

[ ]

In case Dem_GetDTCSelectionResultForClearDTC() returns DEM_WRONG_DTC, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01268]

[ ]

In case Dem_GetDTCSelectionResultForClearDTC() returns E_OK, the Dcm module shall check if application allows to clear the DTC (according to the configuration parameter DcmDspClearDTCCheckFnc). If not, the Dcm module shall send a negative response with NRC set to value from the parameter "ErrorCode".

[SWS_Dcm_01269]

[ ]

In case application allows to clear the DTC, the Dcm module shall check if the DTC can be cleared in the current mode condition (according to the configuration parameter DcmDspClearDTCModeRuleRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

[SWS_Dcm_00005]

[RS_Diag_04058]

If the condition checks are successfully done, the Dcm module shall call Dem_ClearDTC with the following parameter values:

ClientId = Client Id for this Dcm instance (see DcmDemClientRef)

[SWS_Dcm_00705]

[ ]

In case Dem_ClearDTC() returns E_OK, the Dcm module shall send a positive response.

[SWS_Dcm_00707]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_FAILED, the Dcm shall send a negative response 0x22 (conditionsNotCorrect).

[SWS_Dcm_00708]

[ ]

In case Dem_ClearDTC() returns DEM_WRONG_DTC, the Dcm shall send a negative response 0x31 (requestOutOfRange).

[SWS_Dcm_00966]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_BUSY, the Dcm shall send a negative response 0x22 (conditionsNotCorrect).

[SWS_Dcm_01060]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_MEMORY_ERROR, the Dcm shall trigger a negative response with NRC 0x72 (generalProgrammingFailure).

[SWS_Dcm_01408]

[ ]

In case Dem_ClearDTC() returns DEM_WRONG_DTCORIGIN, the Dcm shall trigger a negative response 0x31 (requestOutOfRange).

Read DTC Information (0x19) Service

Service 0x19 allows a client to read the status of server resident Diagnostic Trouble Code (DTC) information.

[SWS_Dcm_00248]

[RS_Diag_04253]

The Dcm module shall implement the UDS Service 0x19.

To setup the retrieval of specific data from the Dem module, the Dcm will call different filter APIs (Dem_SetDTCFilter(), Dem_SetFreezeFrameRecordFilter(), Dem_SelectFreezeFrameData() and Dem_SelectExtendedDataRecord()).

[SWS_Dcm_01043]

[ ]

In case E_NOT_OK is returned by Dem_SetDTCFilter(), the Dcm module shall send a negative response with NRC 0x31 (requestOutOfRange).

[SWS_Dcm_01334]

[ ]

For all sub-functions addressing user defined fault memory, before calling the appropriate Dem API, the Dcm shall add the value 0x0100 to the received selection request parameter MemorySelection in order to match the Dem_DTCOriginType.

The Dcm service processor for UDS service ReadDTCInformation (0x19) can be used in configurations where SAE J1979-2 is supported, so that reported DTC values of SAE J1979-2 services have different DTC values than used for UDS DTCs.

Some manufacturers don't want to fully change to SAE J1979-2 support with UDS and will only support the J1979-2 functionality on the limited UDS subset defined by J1979- 2, wherefore the feature OBD UDS DTC separation was added.

Use of separated OBD and UDS DTCs

[SWS_Dcm_01618]

[RS_Diag_04253]

If DcmDspReadDTCInformationSupportedObdUdsDtcSeparation is set to True, the Dcm service processor for all diagnostic requests according to SAE J1979-2 shall use the Dem API Dem_SelectDTC with the parameter DTCFormat set to DEM_DTC_FORMAT_OBD_3BYTE to query and process DTC related information.

[SWS_Dcm_01619]

[RS_Diag_04253]

If DcmDspReadDTCInformationSupportedObdUdsDtcSeparation is set to False, the Dcm service processor for all diagnostic requests according to SAE J1979-2 shall use the Dem API Dem_SelectDTC with the parameter DTCFormat set to DEM_DTC_FORMAT_UDS to query and process DTC related information.

[SWS_Dcm_01343]

[ ]

For services with FunctionalGroupIdentifier as parameter in the request, the Dcm shall only process request messages with FunctionalGroupIdentifier equal to 0x33.

[SWS_Dcm_01344]

[ ]

For services with FunctionalGroupIdentifier as parameter in the request and FunctionalGroupIdentifier unequal to 0x33, the Dcm shall return NRC 0x31 (RequestOutOfRange).

Subfunctions 0x01, 0x07 and 0x12

UDS Service 0x19 with subfunctions 0x01 or 0x12 requests the ECU to report the number of DTCs matching tester-defined criteria. The service request contains the parameter:

DTCStatusMask

UDS Service 0x19 with subfunction 0x07 requests the ECU to report the number of DTCs matching tester-defined criteria. The service request contains the parameters:

DTCSeverityMask

DTCStatusMask

[SWS_Dcm_00376]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x01, 0x07 or 0x12, the Dcm module shall use the data in the response message according to Table 7.4

Table 7.4: Subfaunction 0x01, 0x07 and 0x12 response values

[SWS_Dcm_00293]

[RS_Diag_04058]

[RS_Diag_04067]

When responding to UDS Service 0x19 with subfunction 0x01, 0x07 or 0x12, the Dcm module shall calculate the number of DTCs using Dem_GetNumberOfFilteredDTC() after having set the DEM-filter with Dem_SetDTCFilter() using the parameter values according to Table 7.5.

Table 7.5: Dem_SetDTCFilter() parameters values for subfunctions 0x01, 0x07 and 0x12

Subfunctions 0x02, 0x0A, 0x13, 0x15 and 0x17

UDS Service 0x19 with subfunctions 0x02 or 0x13 requests the DTCs (and their associated status) that match certain conditions. The service request contains the parameter:

DTCStatusMask

UDS Service 0x19 with subfunction 0x0A requests all supported DTCs and their associated status. UDS Service 0x19 with subfunction 0x15 requests all DTCs with permanent status.

[SWS_Dcm_00377]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x02, 0x0A, 0x13, 0x15 or 0x17, the Dcm module shall use the data in the response message according to Table 7.6.

Table 7.6: Subfunction 0x02, 0x0A, 0x13, 0x15 and 0x17 eesponse values

Read user defined memory by status mask authentication check

[SWS_Dcm_01545]

[RS_Diag_04233]

On reception of the UDS Service ReadDTCInformation (0x19) with subfunction reportUserDefMemoryDTCByStatusMask (0x17), the Dcm shall check if the access to the selected user defined memory in parameter MemorySelection is authenticated and read the DTC information only if:

for that user defined fault memory the DcmDspReadDTCInformationUserDefinedFaultMemoryRoleId matching the MemorySelection and a role is configured via DcmDspReadDTCInformationUserDefinedFaultMemoryRoleRef and the verification according to [SWS_Dcm_01479] was successful or

the active white list on that connection has for that requested user defined memory selection one entry.

According to [SWS_Dcm_01545] the authentication checks are only executed if DcmDspAuthentication is configured. In case of a failed authentication the NRC handling is according to [SWS_Dcm_01544] and [SWS_Dcm_01551] applies.

[SWS_Dcm_00008]

[ ]

On reception of a UDS Service 0x19 request with subfunction 0x02 and 0x13 and if the result of the bitwise AND operation between the DTCStatusMask received within the request message and the DTCStatusAvailabilityMask reported by the DEM is equal to 0, the Dcm module shall answer positively with 0 DTC.

[SWS_Dcm_00378]

[RS_Diag_04058]

[RS_Diag_04067]

When responding to UDS Service 0x19 with subfunctions 0x02, 0x0A, 0x13, 0x15 or 0x17, the Dcm module shall obtain the records with DTCs (and their associated status) by repeatedly calling Dem_GetNextFilteredDTC() after having configured the filter with Dem_SetDTCFilter() using the parameter values according to Table 7.7.

Table 7.7: Dem_SetDTCFilter() parameters values for subfunctions 0x02, 0x0A, 0x13, 0x15 and0x17

Note:

The Dcm module can get an indication of the number of records that will be found using Dem_GetNextFilteredDTC() by using Dem_GetNumberOfFilteredDTC(). This allows the implementation to calculate the total size of the response before cycling through the DTCs.

The value 0x00 used as DTCStatusMask for the subfunctions 0x0A and 0x15 disables the status byte filtering in Dem_SetDTCFilter().

[SWS_Dcm_00828]

[ ]

In case of paged buffer support is disabled, the Dcm module shall not insert zero-padded DTCs to the response of UDS Service 0x19 with subfunctions 0x02, 0x0A, 0x13, 0x15 or 0x17.

When using paged buffer mechanism, in some case, it's possible that the number of DTC matching the filter change between the calculation of the total size, needed for the first page transmission, and the sending of the further pages. For this reason, the following requirement apply :

[SWS_Dcm_00587]

[ ]

In case of paged buffer support is enabled, The Dcm shall limit the response size to the size calculated when sending the first page. If more DTCs match the filter after this sending, the additional DTCs shall not be considered.

[SWS_Dcm_00588]

[ ]

In case of paged buffer support is enabled,The Dcm shall pad the response with the size calculated when sending the first page. If less DTC match the filter after this sending, the missing DTCs shall be padded with 0 value as defined in 15031-6 [16].

[SWS_Dcm_01229]

[ ]

If Dem_GetNextFilteredDTC() returns DEM_NO_SUCH_ELEMENT and at least one matching element could be retrieved before, the Dcm shall send a positive response including these data elements.

[SWS_Dcm_01230]

[ ]

If Dem_GetNextFilteredDTC() returns DEM_NO_SUCH_ELEMENT and at no matching element could be retrieved before, the Dcm shall send a positive response only for service and subservice and additional parameters required within a positive response.

Subfunction 0x08

UDS Service 0x19 with subfunction 0x08 requests the DTCs and the associated status that match a tester-defined severity mask record. The service request contains the following parameters:

DTCSeverityMask

DTCStatusMask

[SWS_Dcm_00379]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x08, the Dcm module shall use the data in the response message according to Table 7.8.

Table 7.8: Subfunction 0x08 response values

[SWS_Dcm_00380]

[ ]

When responding to UDS Service 0x19 with subfunction 0x08, the Dcm module shall obtain the DTCAndSeverityRecords by repeatedly calling Dem_GetNextFilteredDTCAndSeverity() after having configured the filter with Dem_SetDTCFilter() using the parameter values according to Table 7.9.

Table 7.9: Dem_SetDTCFilter() parameters values for Subfunction 0x08

Note:

The Dcm module can get an indication of the number of records that will be found using Dem_GetNextFilteredDTCAndSeverity() by using Dem_GetNumberOfFilteredDTC().

Subfunction 0x09

UDS Service 0x19 with subfunction 0x09 requests the severity information of a DTC. The service request contains the parameter:

DTCMaskRecord

[SWS_Dcm_00381]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x09, the Dcm module shall use the data in the response message according to Table 7.10.

Table 7.10: Subfunction 0x09 response values

[SWS_Dcm_01402]

[ ]

To select the DTC, the Dcm module shall call the API Dem_SelectDTC() with the following parameter values:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

DTC: DTC from the service request

DTCFormat: DEM_DTC_FORMAT_UDS

DTCOrigin: DEM_DTC_ORIGIN_PRIMARY_MEMORY

[SWS_Dcm_01403]

[ ]

To retrieve the DTCSeverityMask of the selected DTC, the Dcm shall call Dem_GetSeverityOfDTC() with the following parameter value:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

[SWS_Dcm_01404]

[ ]

To retrieve the DTCFunctionalUnit of the selected DTC, the Dcm shall call Dem_GetFunctionalUnitOfDTC() with the following parameter value:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

[SWS_Dcm_01405]

[ ]

To retrieve the statusOfDTC of the selected DTC, the Dcm shall call Dem_GetStatusOfDTC() with the following parameter value:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

[SWS_Dcm_01226]

[ ]

If Dem_GetFunctionalUnitOfDTC() returns DEM_WRONG_DTC or DEM_WRONG_DTCORIGIN, the Dcm shall send a NRC 0x31 (requestOutOfRange).

[SWS_Dcm_01240]

[ ]

If Dem_GetSeverityOfDTC() returns DEM_WRONG_DTC, the Dcm shall send a NRC 0x31 (requestOutOfRange)

[SWS_Dcm_01406]

[ ]

If Dem_GetStatusOfDTC() returns DEM_WRONG_DTC or DEM_WRONG_DTCORIGIN, the Dcm shall send a NRC 0x31 (requestOutOfRange).

Subfunctions 0x06/0x19

The UDS Service 0x19 with subfunction 0x06 or 0x19 requests a specific Extended Data Records for a specific DTC. The service request contains the parameters:

DTCMaskRecord

DTCExtendedDataRecordNumber

Read user defined memory extended data record authentication check

[SWS_Dcm_01547]

[RS_Diag_04233]

On reception of the UDS Service ReadDTCInformation (0x19) with subfunction reportUserDefMemoryDTCExtDataRecordByDTCNumber (0x19), the Dcm shall check if the access to the selected user defined memory in parameter MemorySelection is authenticated and read the DTC information only if:

for that user defined fault memory the DcmDspReadDTCInformationUserDefinedFaultMemoryRoleId matching the MemorySelection and a role is configured via DcmDspReadDTCInformationUserDefinedFaultMemoryRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for that requested user defined memory selection one entry.

According to [SWS_Dcm_01537] the authentication checks are only executed if DcmDspAuthentication is configured. In case of a failed authentication the NRC handling is according to [SWS_Dcm_01485] and [SWS_Dcm_01544] applies.

[SWS_Dcm_00386]

[ ]

Upon reception of UDS Service 0x019 with subfunction 0x06 or 0x19, the Dcm shall retrieve from the Dem the stored extended data records for the requested DTC and origin.

[SWS_Dcm_00295]

[RS_Diag_04058]

When responding to UDS Service 0x19 with subfunction 0x06 or 0x19, the Dcm module shall calculate the statusOfDTC by first calling Dem_SelectDTC() with the parameters values set according to Table 7.11 and then Dem_GetStatusOfDTC() with ClientId = Client Id for this Dcm instance (see DcmDemClientRef).

Table 7.11: Dem_SelectDTC() parameters values for subfunctions 0x06 and 0x19

[SWS_Dcm_00841]

[ ]

If Dem_GetNextExtendedDataRecord() returns E_OK and BufSize 0 (empty buffer), the Dcm module shall omit the DTCExtendedDataRecordNumber for the related record in the response of service 0x19 0x06/0x19.

[SWS_Dcm_00382]

[ ]

When responding to UDS Service 0x19 with subfunction 0x06 or 0x19, the Dcm module shall calculate the DTCExtendedDataRecord by first calling Dem_SelectExtendedDataRecord() with the parameter values set according to Table 7.12 and then call Dem_GetNextExtendedDataRecord() repeatedly until DEM_NO_SUCH_ELEMENT is returned.

Table 7.12: Dem_SelectExtendedDataRecord() parameters values for subfunctions 0x06 and 0x19

The Dcm module shall obtain the size of the extended data record by using Dem_GetSizeOfExtendedDataRecordSelection().

Subfunction 0x03

UDS Service 0x19 with subfunction 0x03 allows an external tester to request all stored snapshot records for all DTCs in an ECU.

Support of UDS Service 0x19 with subfunction 0x03

[SWS_Dcm_01640]

[RS_Diag_04250]

The Dcm shall support UDS Service 0x19 with subfunction 0x03 according to ISO 14229-1:2020 [8].

Subfunctions 0x04 and 0x18

Using UDS Service 0x19 with subfunction 0x04 or 0x18, an external tester can request snapshot record data for one or all snapshot records of a specific DTC.

To process the UDS Service 0x19 04 or 0x19 18, the Dcm supports the option to process the entire service BSW internally while interacting with the Dem and the option to leave the service processing to an external service processor.

Use of internal service processor to read snapshot records

[SWS_Dcm_01623]

[RS_Diag_04180]

[RS_Diag_04205]

If a DcmDsdService for service 0x19 with a DcmDsdSubService for subfunction 0x04 or 0x18 is configured and DcmDsdSubServiceFnc is not configured for that service, the Dcm shall process the diagnostic request according to ISO 14229-1 [1].

Use of external service processor to read snapshot records

[SWS_Dcm_01624]

[RS_Diag_04205]

If a DcmDsdService for service 0x19 with a DcmDsdSubService for subfunction 0x04 or 0x18 is configured and DcmDsdSubServiceFnc is configured for that service, the Dcm shall leave the processing of the diagnostic request to the external service processor provided in DcmDsdSubServiceFnc.

Figure 7.10: Request DTC Snapshot Record by Snapshot Record Number

Read user defined memory snapshot record authentication check

[SWS_Dcm_01546]

[RS_Diag_04233]

On reception of the UDS Service ReadDTCInformation (0x19) with subfunction reportUserDefMemoryDTCSnapshotRecordByDTCNumber (0x18), the Dcm shall check if the access to the selected user defined memory in parameter MemorySelection is authenticated and read the DTC information only if:

for that user defined fault memory the DcmDspReadDTCInformationUserDefinedFaultMemoryRoleId matching the MemorySelection and a role is configured via DcmDspReadDTCInformationUserDefinedFaultMemoryRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for that requested user defined memory selection one entry.

According to [SWS_Dcm_01546] the authentication checks are only executed if DcmDspAuthentication is configured. In case of a failed authentication the NRC handling is according to [SWS_Dcm_01485] and [SWS_Dcm_01551] applies.

Subfunction 0x05

UDS Service 0x19 with subfunction 0x05 allows an external tester to request FreezeFrame information for a specific FreezeFrame record number. The service request contains parameter:

DTCStoredDataRecordNumber

Due to Dem limitation, the diagnostic service $19 05 is limited to the OBD legislative freeze frame.

[SWS_Dcm_00632]

[ ]

On reception of service 0x19 with subfunction 0x05, if the record number of the diagnostic request is different from 0x00, the Dcm module shall send a negative response with NRC 0x31 (request out of range).

[SWS_Dcm_00574]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x05 and DTCStoredDataRecordNumber is 0x00, the Dcm module shall use the data in the response message according to Table 7.13.

Table 7.13: Subfunction 0x05 response values

[SWS_Dcm_00388]

[RS_Diag_04058]

When responding to UDS Service 0x19 with subfunction 0x05 and DTCStoredDataRecordNumber is 0x00, the Dcm shall compose the OBD Freezeframe by looping all DcmDspPid and collecting all DcmDspPidData which are configured for service 0x02 by calling Dem_DcmReadDataOfOBDFreezeFrame() for the Data Element. The Dcm shall compose the DidId by adding 0xF400 to the Pid, and calculate padding and supported informations.

[SWS_Dcm_01193]

[ ]

When responding to UDS Service 0x19 with subfunction 0x05 and DTCStoredDataRecordNumber is 0x00, the Dcm shall call Dem_DcmGetDTCOfOBDFreezeFrame() with FrameNumber 0x00 and DTCFormat DEM_DTC_FORMAT_UDS to retrieve the DTC of the provided FreezeFrame.

[SWS_Dcm_00389]

[RS_Diag_04058]

When responding to UDS Service 0x19 with subfunction 0x05 and DTCStoredDataRecordNumber is 0x00, the Dcm module shall obtain the status of the DTC by first calling Dem_SelectDTC() with the following parameters:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

DTC: DTC as defined in [SWS_Dcm_00388]

DTCOrigin: DEM_DTC_ORIGIN_PRIMARY_MEMORY

and then Dem_GetStatusOfDTC() with the following parameter:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

Subfunctions 0x0B, 0x0C, 0x0D and 0x0E

An external test tool can request the first occurred or most recent failed or confirmed DTC and associated status, by sending the UDS Service request 0x19 including one of the following sub-functions 0x0B, 0x0C, 0x0D, 0x0E

[SWS_Dcm_00392]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x0B, 0x0C, 0x0D or 0x0E, the Dcm module shall use the data in the response message according to Table 7.14.

Table 7.14: Subfunctions 0x0B, 0x0C, 0x0D and 0x0E response values

[SWS_Dcm_00393]

[RS_Diag_04058]

For the purpose of responding to UDS Service 0x19 with subfunctions 0x0B, 0x0C, 0x0D or 0x0E, the Dcm module shall obtain the StatusOfDtc by calling Dem_GetStatusOfDTC() with the following parameter values:

ClientId :Client Id for this Dcm instance (see DcmDemClientRef

DTC: the DTC value as defined in [SWS_Dcm_00466]

DTCOrigin: DEM_DTC_ORIGIN_PRIMARY_MEMORY

[SWS_Dcm_00466]

[ ]

For the purpose of responding to UDS Service 0x19 with subfunctions 0x0B, 0x0C, 0x0D or 0x0E, the Dcm shall obtain the DTC with Dem_GetDTCByOccurrenceTime() using the parameter values according to Table 7.15.

Table 7.15: Dem_GetDTCByOccurrenceTime() parameters values for subfunctions 0x0B, 0x0C, 0x0D and 0x0E

[SWS_Dcm_00766]

[ ]

If the Dcm received DEM_NO_SUCH_ELEMENT by calling Dem_GetDTCByOccurrenceTime it shall reply with a positive response and empty DTCAndStatusRecord.

Subfunction 0x14

An external test tool may request an ECU to report the FaultDetectionCounter for all DTCs with a "Prefailed" status, by sending a UDS Service request 0x19 with subfunction 0x14.

[SWS_Dcm_00464]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x14, the Dcm module shall use the data in the response message according to Table 7.16.

Table 7.16: Subfunction 0x14 response values

[SWS_Dcm_00465]

[RS_Diag_04058]

When responding to UDS Service 0x19 with subfunctions 0x14, the Dcm module shall obtain the DTCFaultCounter of every DTCs with status "prefailed" by repeatedly calling Dem_GetNextFilteredDTCAndFDC() after having configured the filter with Dem_SetDTCFilter() using the parameter values according to Table 7.17.

Table 7.17: Dem_GetNextFilteredDTCAndFDC() parameters values for subfunctions 0x14

[SWS_Dcm_00681]

[ ]

The Dcm module shall obtain the number of records that will be found using Dem_GetNextFilteredDTCAndFDC() by using Dem_GetNumberOfFilteredDTC().

[SWS_Dcm_00519]

[ ]

The calls to Dem_SetDTCFilter() with parameter FilterForFaultDetectionCounter set to YES shall be done in the context of the Dcm_MainFunction

This allows the implementation to calculate the total size of the response before cycling through the DTCs.

[SWS_Dcm_01232]

[ ]

If Dem_GetNextFilteredDTCAndFDC() returns DEM_NO_SUCH_ELEMENT and at least one matching element could be retrieved before, the Dcm shall send a positive response including these data elements.

[SWS_Dcm_01233]

[ ]

If Dem_GetNextFilteredDTCAndFDC() returns DEM_NO_SUCH_ELEMENT and no matching element could be retrieved before, the Dcm shall send a positive response only for service and subservice.

Subfunction 0x1A

UDS Service 0x19 with subfunction 0x1A request the Dcm to retrieve all DTCs that support an extended data record.

Support of UDS Service 0x19 with subfunction 0x1A

[SWS_Dcm_01607]

[RS_Diag_04250]

The Dcm shall support UDS Service 0x19 with subfunction 0x1A according to ISO 14229-1:2020 [8].

To retrieve the DTCs that support an extended data record, the Dem provides the API Dem_SetDTCFilterByExtendedDataRecordNumber that allows to set a filter for an extended data record. Subsequent calls to Dem_GetNextFilteredDTC provide the requested data.

The positive response consists of an enumeration of DTC number and DTC status. The Dcm does not define any specific order in which the DTCs are reported in the positive response message.

Positive response of UDS Service 0x19 with subfunction 0x1A

[SWS_Dcm_01608]

[RS_Diag_04250]

If one or more extended data record is/are supported for the requested DTCExtDataRecordNumber, the Dcm shall send a positive response including all DTCs and the DTC status.

Negative response of UDS Service 0x19 with subfunction 0x1A

[SWS_Dcm_01609]

[RS_Diag_04250]

If no extended data record is supported for the requested DTCExtDataRecordNumber, the Dcm shall send a negative response with NRC 0x31 (RequestOutOfRange).

Subfunction 0x42

UDS Service 0x19 with subfunction 0x42 requests WWH OBD DTCs matching a DTC status mask a severity mask record. The service request contains the following parameters:

FunctionalGroupIdentifier

DTCSeverityMask

DTCStatusMask

[SWS_Dcm_01128]

[ ]

The Dcm shall reject request messages for subFunction 0x42 with FunctionalGroupIdentifier unequal to 0x33 by returning NRC 0x31 (requestOutOfRange)

[SWS_Dcm_01129]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x42, the Dcm module shall use the data in the response message according to Table 7.18.

Table 7.18: Subfunction 0x42 response values

[SWS_Dcm_01130]

[ ]

When responding to UDS Service 0x19 with subfunction 0x42, the Dcm module shall obtain the DTCAndSeverityRecords by repeatedly calling Dem_GetNextFilteredDTCAndSeverity() after having configured the filter with Dem_SetDTCFilter() using the parameter values according to Table 7.19.

Table 7.19: Dem_GetNextFilteredDTCAndSeverity() parameters values for subfunctions 0x42

[SWS_Dcm_01131]

[ ]

The return values of Dem_GetNextFilteredDTCAndSeverity shall be filled according to Table 7.20.

Table 7.20: Dem_GetNextFilteredDTCAndSeverity return values

Note:

The Dcm module can get an indication of the number of records that will be found using Dem_GetNextFilteredDTCAndSeverity() by using Dem_GetNumberOfFilteredDTC().

Subfunction 0x55

With UDS Service 0x19 with sub-function 0x55 a client can retrieve a list of OBD DTCs with the "permanent DTC" status. The service request contains the following parameter:

FunctionalGroupIdentifier

[SWS_Dcm_01345]

[ ]

When sending a positive response to UDS Service 0x19 with subfunction 0x55, the Dcm module shall use the following data in the response message according to Table 7.21.

Table 7.21: Subfunction 0x55 response values

Note :

When responding to UDS Service 0x19 with sub-function 0x55, the Dcm module could obtain the DTCAndStatusRecords by repeatedly calling Dem_GetNextFilteredDTC() after having configured the filter with Dem_SetDTCFilter() using the parameter values according to Table 7.22.

Table 7.22: Dem_GetNextFilteredDTCAndSeverity() parameters values for subfunctions 0x42

The Dcm module can get an indication of the number of records that will be found using Dem_GetNextFilteredDTC() by using Dem_GetNumberOfFilteredDTC().

[SWS_Dcm_01346]

[ ]

When responding to UDS Service 0x19 with sub-function 0x55 and Dem_GetTranslationType returns a Dem_DTCTranslationFormatType different to 0x02 (DEM_DTC_TRANSLATION_SAEJ1939_73) or 0x04 (DEM_DTC_TRANSLATION_J2012DA_FORMAT_04), the Dcm module shall return NRC 0x10 (generalReject).

Subfunction 0x56

UDS Service 0x19 with subfunction 0x1A request the Dcm to retrieve all DTCs that are assigned to an DTC readiness group identifier.

Support of UDS Service 0x19 with subfunction 0x56

[SWS_Dcm_01610]

[RS_Diag_04250]

The Dcm shall support UDS Service 0x19 with subfunction 0x56 according to ISO 14229-1:2020 [8].

To retrieve the DTCs that are assigned to an DTC readiness group, the Dem provides the API Dem_SetDTCFilterByReadinessGroup that allows to set a filter for a readiness group. Subsequent calls to Dem_GetNextFilteredDTC provide the requested data.

The positive response consists of an enumeration of DTC number and DTC status. The Dcm does not define any specific order in which the DTCs are reported in the positive response message.

Positive response of UDS Service 0x19 with subfunction 0x56

[SWS_Dcm_01611]

[RS_Diag_04250]

If one or more DTCs support the requested DTC readiness group identifier, the Dcm shall send a positive response including all DTCs and the DTC status.

Negative response of UDS Service 0x19 with subfunction 0x56

[SWS_Dcm_01612]

[RS_Diag_04250]

If no DTC supports the requested DTC readiness group, the Dcm shall send a negative response with NRC 0x31 (requestOutOfRange).

ReadDataByIdentifier (0x22) Service

[SWS_Dcm_00253]

[ ]

The Dcm module shall implement the UDS Service ReadDataByIdentifier (0x22)

[SWS_Dcm_01335]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), if the number of requested DID exceeds the configured maximum number of data identifiers (refer to configuration parameter DcmDspMaxDidToRead), the Dcm module shall send NRC 0x13 (Incorrect message length or invalid format)

With UDS Service 0x22, the tester can request the value of one or more DIDs.

Read UDS DID authentication check

[SWS_Dcm_01548]

[RS_Diag_04233]

On reception of the UDS Service ReadDataByIdentifier (0x22), the Dcm shall check if the access to all requested DIDs outside the range 0xF200-0xF8FF is authenticated and read the data identifiers only if:

for that read DID a role is configured via DcmDspDidReadRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for each requested DID one entry with read access that matches that DID.

Read Dynamically defined DID authentication check

[SWS_Dcm_01549]

[RS_Diag_04233]

On reception of the UDS Service ReadDataByIdentifier (0x22), the Dcm shall check for all requested DIDs inside the range 0xF200-0xF3FF if the content is based of DIDs or parts of DIDs that are authenticated and read the data identifiers only if:

for those read DIDs a role is configured via DcmDspDidReadRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for each requested DID one entry with read access that matches those DIDs.

[SWS_Dcm_00438]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22) , for every requested DID the Dcm module shall check if the DID is supported (see configuration parameter DcmDspDid and DcmDspDidRange) If none of the requested DIDs is supported, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00651]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22) with DID in the range 0xF200 to 0xF3FF, the Dcm module shall check if the DID can be dynamically defined (the DcmDspDidInfo it references has the DcmDspDidDynamicallyDefined set to true). If yes, if this DID has not been dynamically defined yet by calls to the DynamicallyDefineDataIdentifier (0x2C) service, i.e. it has no data sources defined, the Dcm module shall send NRC 0x31 (Requestout of range).

[SWS_Dcm_00652]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22) with DID in the range 0xF200 to 0xF3FF, if verification has been successfully done (see [SWS_Dcm_00651]) and the dynamic DID has been defined with a DID source (see [SWS_Dcm_00646]), the Dcm module shall use the configuration of this DID source to read the data.

[SWS_Dcm_00864]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22) with DID in the range 0xF200 to 0xF3FF, if verification has been successfully done (see [SWS_Dcm_00651]) and the dynamic DID has been defined with a DID source (see [SWS_Dcm_00646]), the Dcm module shall do the session, security and mode dependencies checks for all source DIDs in case the configuration parameter DcmDspDDDIDcheckPerSourceDID is set to TRUE.

[SWS_Dcm_00865]

[ ]

In case the configuration parameter DcmDspDDDIDcheckPerSourceDID is set to FALSE, there is no session, security or mode dependencies check for the source DIDs.

Note:

In case there is a need to validate the session or security dependencies always, the DDDID should be cleared by any security and session transitions.

[SWS_Dcm_00653]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22) with DID in the range 0xF200 to 0xF3FF, if verification has been successfully done (see [SWS_Dcm_00651]) and the dynamic DID has been defined with a memory address (see [SWS_Dcm_00646]), the Dcm module shall use the callout Dcm_ReadMemory to read the data.

[SWS_Dcm_00561]

[ ]

If a DID is set as unused (DcmDspDidUsed set to FALSE), the Dcm shall consider the DID as not supported (according to [SWS_Dcm_00438])

[SWS_Dcm_00433]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID the Dcm module shall check if the DID has a Read access configured (see configuration parameter DcmDspDidRead in DcmDspDidInfo). If none of the DID has a Read access, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00434]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID the Dcm module shall check if the DID can be read in the current session (see configuration parameter DcmDspDidReadSessionRef). If none of the DID can be renden in the current session, the Dcm module shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00435]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID the Dcm module shall check if the DID can be read in the current security level (see configuration parameter DcmDspDidReadSecurityLevelRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

[SWS_Dcm_00819]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID the Dcm module shall check if the DID can be read in the current mode condition (according to the configuration parameter DcmDspDidReadModeRuleRef). If not, the Dcm module shall send the calculated negative response of the referenced DcmModeRule.

[SWS_Dcm_00439]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID outside the OBD range (0xF400-0xF8FF), the Dcm module shall request the application if the DID can be read by calling the configured function (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataConditionCheckReadFnc) on each data of the DID or call the associated ConditionCheckRead operation (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR). If not (one function returns E_NOT_OK) , the Dcm module shall send a negative response with NRC set to value from the parameter "ErrorCode" of DcmDspDataConditionCheckReadFnc function or ConditionCheckRead operation.

Note:

This requirement exceeds the standard ConditionCheck behavior as described by ISO 14229-1 "NRC handling for ReadDataByIdentifier service" , because it is not restricted to use NRC 0x22 in a negative response.

[SWS_Dcm_00440]

[ ]

If the requested DID references other DID using DcmDspDidRef, the Dcm module shall process the verification and the reading of every referenced DID and concatenate the response data without any gaps based on the sequence in the configuration.

DcmDspDidRef shall not reference the same DID reference twice

[SWS_Dcm_CONSTR_06023]

[ ]

DcmDspDid container shall not include the same DcmDspDidRef parameters more than once.

Dependency for DcmDspDataEcuSignal

[SWS_Dcm_CONSTR_06057]

[ ]

DcmDspDataEcuSignal shall be only present if DcmDspDataUsePort is set to USE_ECU_SIGNAL.

Dependency for DcmDspDataEndianness

[SWS_Dcm_CONSTR_06058]

[ ]

In case DcmDspDataEndianness is not configured, the DcmDspDataDefaultEndianness shall be used instead.

Dependency for DcmDspDataReadDataLengthFnc

[SWS_Dcm_CONSTR_06061]

[ ]

DcmDspDataReadDataLengthFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Dependency for DcmDspDataReadFnc

[SWS_Dcm_CONSTR_06062]

[ ]

DcmDspDataReadFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

[SWS_Dcm_01385]

[ ]

If the DID dataRecord has bytes, not defined by any data element, the Dcm shall fill these bytes with the value 0x00.

[SWS_Dcm_01431]

[ ]

If the configuration parameter DcmDspDidSize is configured, the Dcm shall enforce the DID data to have the configured size.

Atomic BndM read operation

[SWS_Dcm_01587]

[RS_Diag_04243]

After all verification (see [SWS_Dcm_00433], [SWS_Dcm_00434], [SWS_Dcm_00435], [SWS_Dcm_00436]) the Dcm module shall get for every requested DID with DcmDspDidUsePort set to USE_ATOMIC_BNDM and outside the OBD range (F400-F8FF) the data values by reading the data from the associated BlockId from the BndM (DcmDspDidBndMBlockIdRef) using the block specific reading function BndM_GetBlockPtr_<BlockId.Shortname>.

UDS DID

[SWS_Dcm_00578]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID outside the OBD range (F400-F8FF), after all verification (see [SWS_Dcm_00433], [SWS_Dcm_00434] and [SWS_Dcm_00435]), If the data is configured as a "ECU signal" of the IoHwAb (parameter DcmDspDataUsePort), the Dcm shall call the Api IoHwAb_Dcm_Read<EcuSignalName >() (parameter DcmDspDataReadEcuSignal) to get the Data. In this case, the requirements [SWS_Dcm_00439], [SWS_Dcm_00436] and [SWS_Dcm_00437] shall not apply.

[SWS_Dcm_00436]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID outside the OBD range (F400-F8FF), the Dcm module shall for each signal (DcmDspDidSignal) with a dynamic data length (DcmDspDataType is set to UINT8_DYN): call either the configured function DcmDspDataReadDataLengthFnc (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY) or the associated ReadDataLength operation (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) to get the data length in byte.

[SWS_Dcm_00437]

[ ]

After all verification (see [SWS_Dcm_00433], [SWS_Dcm_00434], [SWS_Dcm_00435] and [SWS_Dcm_00436]) the Dcm module shall get for every requested DID outside the OBD range (F400-F8FF), all the data values by calling all the configured function (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataReadFnc) or call all the associated ReadData operations (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) or read all the associated SenderReceiver interfaces (if parameter DcmDspDataUsePort set to USE_DATA_SENDER_RECEIVER or to USE_DATA_SENDER_RECEIVER_AS_SERVICE).

[SWS_Dcm_01432]

[ ]

After all verification (see [SWS_Dcm_00433], [SWS_Dcm_00434], [SWS_Dcm_00435] and [SWS_Dcm_00436]) the Dcm module shall get for every requested DID with DcmDspDidUsePort set to USE_ATOMIC_SENDER_RECEIVER_INTERFACE, USE_ATOMIC_SENDER_RECEIVER_INTERFACE_AS_SERVICE or USE_ATOMIC_NV_DATA_INTERFACE and outside the OBD range (F400-F8FF) the data values by reading the associated sender-receiver or NvDataInterface DataServices_{DID}.

[SWS_Dcm_00560]

[ ]

If the data is configured as a BlockId of the NvRam (parameter DcmDspDataUsePort), the Dcm shall call the Api NvM_ReadBlock() with the BlockId (parameter DcmDspDataBlockIdRef)

Note :

For more information, refer to [17, SWS-NVRAMManager].

[SWS_Dcm_00638]

[ ]

To serialize the required AUTOSAR data types (signed- and unsigned integer) into the response message of ReadDataByIdentifier responses, the target endianness configured in DcmDspDataEndianness shall be considered for DcmDspData elements having DcmDspDataUsePort set to USE_DATA_SENDER_RECEIVER, USE_DATA_SENDER_RECEIVER_AS_SERVICE, USE_ECU_SIGNAL.

Dependency for DcmDspDataEndianness

[SWS_Dcm_CONSTR_06070]

[ ]

In case DcmDspDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

OBD DID

[SWS_Dcm_00481]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID inside the OBD range (F400-F4FF), the Dcm module shall get the DID value as defined for OBD Service $01 (see [SWS_Dcm_00407], [SWS_Dcm_00408], [SWS_Dcm_00943], [SWS_Dcm_00621], [SWS_Dcm_00622], [SWS_Dcm_00623], [SWS_Dcm_00944] and [SWS_Dcm_00718] ), if DcmDspEnableObdMirror is set to true.

[SWS_Dcm_00482]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID inside the OBD Monitor range (F600-F6FF), the Dcm module shall get the DID value as defined for OBD Service $06 (see [SWS_Dcm_00957], [SWS_Dcm_00958], [SWS_Dcm_00945] and [SWS_Dcm_00956])

[SWS_Dcm_00483]

[ ]

On reception of the UDS Service ReadDataByIdentifier (0x22), for every requested DID inside the OBD InfoType range (F800-F8FF), the Dcm module shall get the DID value as defined for OBD Service $09 (see [SWS_Dcm_00422], [SWS_Dcm_00423] and [SWS_Dcm_00949] without including the number of data items within the response, if DcmDspEnableObdMirror is set to true.

[SWS_Dcm_01195]

[ ]

If DcmDspEnableObdMirror is set to true, an explicitly configured DID inside the OBD range (F400-F4FF) and the OBD InfoType range (F800-F8FF) shall use the UDS interface.

[SWS_Dcm_01197]

[ ]

If DcmDspEnableObdMirror is set to FALSE, all requests within the OBD DID range shall use the UDS interface.

If DcmDspEnableObdMirror is set to FALSE ([SWS_Dcm_01197]) or the DID is explicitly configured inside the OBD PID range (F400-F4FF) ([SWS_Dcm_01195]), the access to the OBD data shall be given in the following way:

[SWS_Dcm_01379]

[ ]

On reception of an UDS Service ReadDataByIdentifier (0x22) request with only "availability OBDDataIdentifier" as parameter, the Dcm shall respond with the corresponding supported (=configured) DIDs in the OBD range (F400-F4FF).

[SWS_Dcm_01380]

[ ]

On reception of an UDS Service ReadDataByIdentifier (0x22) request with only OBDDataIdentifier that are not "availability OBDDataIdentifier", the Dcm shall obtain the current value of these OBDDataIdentifier by invoking the configured Xxx_ReadData() functions for every data of the OBDDataIdentifier and shall return these values as response to Service 0x22.

[SWS_Dcm_01382]

[ ]

If an OBDDataIdentifier contains support information (presence of DcmDspDidDataSupportInfo container), the Dcm shall add the support information in the diagnostic response.

[SWS_Dcm_01383]

[ ]

If an OBDDataIdentifier contains support information (presence of DcmDspDidDataSupportInfo container), the Dcm shall calculate the support information value according to the available data for this DID: for every DcmDspData container existing for this DID, the associated support information bits, referenced in DcmDspDidDataSupportInfo, shall be set to one.

[SWS_Dcm_01384]

[ ]

When responding to UDS Service ReadDataByIdentifier (0x22) with OBDDataIdentifier, the Dcm shall put fill-bytes between DcmDspData in the OBDDataIdentifier whenever content bytes are missing, in order to fit to the DID size (see configuration parameter DcmDspDidSize).

[SWS_Dcm_01386]

[ ]

To serialize the required AUTOSAR data types (signed and unsigned integer) into the response message of ReadDataByIdentifier (0x22) OBDDataIdentifier responses the target endianness configured in DcmDspDataEndianness shall be considered for DcmDspData elements having DcmDspDataUsePort set to {USE_DATA_SENDER_RECEIVER, USE_DATA_SENDER_RECEIVER_AS_SERVICE, USE_ECU_SIGNAL}. In case DcmDspDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

If DcmDspEnableObdMirror is set to FALSE or the DID is explicitly configured inside the OBD InfoType range (F800-F8FF), the access to the OBD data shall be given in the following way:

[SWS_Dcm_01387]

[ ]

On reception of an UDS Service ReadDataByIdentifier (0x22) request with one or more "availability OBDInfoTypeDataIdentifier" as parameter, the Dcm module shall respond with the corresponding supported (=configured) DIDs in the OBD range (F800-F8FF).

[SWS_Dcm_01389]

[ ]

On reception of an UDS Service ReadDataByIdentifier (0x22) request with an OBDInfoTypeDataIdentifier that is not an "availability OBDInfoTypeDataIdentifier", the Dcm module shall obtain the value of this OBDInfoTypeDataIdentifier by invoking all the configured Xxx_ReadData() function for every data of this OBDInfoTypeDataIdentifier and shall return the value as response to Service 0x22.

ReadScalingDataByIdentifier (0x24) Service

[SWS_Dcm_00258]

[ ]

The Dcm module shall implement the UDS Service ReadScalingDataByIdentifier (0x24)

To obtain scaling information, the tester can invoke UDS Service 0x24 with the 2-byte DID as parameter. The configuration of the Dcm contains for each configured DID:

The 2-byte DID (see configuration parameter DcmDspDidIdentifier)

For every data of the DID :

The function GetScalingInformation (see configuration parameters DcmDspDataGetScalingInfoFnc and DcmDspDataUsePort)

The length of the ScalingInfo returned by the GetScalingInformation function (see configuration parameter DcmDspDataScalingInfoSize)

[SWS_Dcm_00394]

[ ]

On reception of a request for UDS Service ReadScalingByIdentifier, the Dcm module shall call every function Xxx_GetScalingInformation() configured for everay data of the DID received in the request and return the data received in the response

[SWS_Dcm_01601]

[ ]

In the context of [SWS_Dcm_00490], the Dcm shall place the received scaling information for every data of a DcmDspDid in the same order as specified by DcmDspDidByteOffset.

Dependency for DcmDspDataGetScalingInfoFnc

[SWS_Dcm_CONSTR_06060]

[ ]

DcmDspDataGetScalingInfoFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

SecurityAccess (0x27) Service

[SWS_Dcm_00252]

[RS_Diag_04005]

The Dcm module shall implement the UDS Service SecurityAccess (0x27)

The purpose of this service is to provide a means to access data and/or diagnostic services, which have restricted access for security, emissions, or safety reasons.

[SWS_Dcm_00321]

[ ]

If the request length is correct, the DSP submodule shall check if the requested subfunction value (access type) is configured in the ECU (see configuration parameter DcmDspSecurityLevel). If the requested subfunction value is not configured, the DSP submodule shall trigger a negative response with NRC 0x12 (SubFunction not supported).

[SWS_Dcm_00323]

[ ]

If the requested subfunction value is configured and a service with subfunction type "requestSeed "(= odd value) has been received and if the requested access type is already active (see Dcm_GetSecurityLevel), the DSP submodule shall set the seed content to 0x00.

[SWS_Dcm_00324]

[ ]

In the other case than the one described in [SWS_Dcm_00323] (access type is not active or "send key" request), if DcmDspSecurityUsePort is set to USE_ASYNCH_CLIENT_SERVER, the DSP submodule shall call the configured operation Xxx_GetSeed() (in case "request seed" is received) or Xxx_CompareKey() (in case "send key" is received).

[SWS_Dcm_00862]

[ ]

On reception of the UDS Service SecurityAccess (0x27) with subfunction type "requestSeed" and if the requested access type is not already active, the Dcm module shall request a seed by calling the configured Xxx_GetSeed() function (if the configuration parameter DcmDspSecurityUsePort is set to USE_ASYNCH_FNC, refer to configuration parameter DcmDspSecurityGetSeedFnc).

Note :

If the static seed mechanism is used, the processing needs to be done by the application implementing the Xxx_GetSeed() and Xxx_CompareKey() functions.

Dependency for DcmDspSecurityGetSeedFnc

[SWS_Dcm_CONSTR_06077]

[ ]

DcmDspSecurityGetSeedFnc shall be present only if DcmDspSecurityUsePort is set to USE_ASYNCH_FNC.

[SWS_Dcm_00863]

[ ]

On reception of the UDS Service SecurityAccess (0x27) with subfunction type "sendKey", if the requested access type is not already active and if the "request seed" for the related access type was executed successfully, the Dcm module shall request the result of a key comparison by calling the configured Xxx_CompareKey() function (if the configuration parameter DcmDspSecurityUsePort is set to USE_ASYNCH_FNC, refer to configuration parameter DcmDspSecurityCompareKeyFnc).

Dependency for DcmDspSecurityCompareKeyFnc

[SWS_Dcm_CONSTR_06075]

[ ]

DcmDspSecurityCompareKeyFnc shall be configured only if DcmDspSecurityUsePort is set to USE_ASYNCH_FNC.

The following list gives as an example, which errors can be detected by the security access service and stored in the error code information:

RequestSequenceError (NRC 0x24), when invalid access type is send at "send key",

RequiredTimeDelayNotExpired (NRC 0x37), when time delay is active (see configuration parameter DcmDspSecurityDelayTime),

ExceededNumberOfAttempts (NRC 0x36), when number of attempts to get security access reaches or exceeds the configured limit (see configuration parameter DcmDspSecurityNumAttDelay), and

InvalidKey (NRC 0x35), when invalid key is send at "send key".

[SWS_Dcm_00325]

[ ]

If the operation CompareKey() returns E_OK, the DSP submodule shall set the new access type with DslInternal_SetSecurityLevel()(see the conversion formula given in ECUC_Dcm_00754 DcmDspSecurityLevel).

[SWS_Dcm_01397]

[RS_Diag_04005]

If Xxx_CompareKey() returns value DCM_E_COMPARE_KEY_FAILED and DcmDspSecurityNumAttDelay is configured, the Dcm shall increment the attempt counter of the security level for which the sendKey subfunction request failed.

[SWS_Dcm_00660]

[ ]

If Xxx_CompareKey() returns value DCM_E_COMPARE_KEY_FAILED and if the number of failed attempts to enter the requested security level (AttemptCounter) is less than the value configured for the DcmDspSecurityNumAttDelay parameter of the requested security level, the Dcm module shall send a negative response with NRC 0x35 (InvalidKey) and shall not change the Dcm internal security level. Note: if DcmDspSecurityNumAttDelay parameter is not configured, the number of failed attempts to enter the requested security level (AttemptCounter) is not considered.

[SWS_Dcm_01349]

[ ]

If Xxx_CompareKey() returns value DCM_E_COMPARE_KEY_FAILED and if the number of failed attempts to enter the requested security level (AttemptCounter) is greater or equal than the value configured for the DcmDspSecurityNumAttDelay parameter of the requested security level, the Dcm module shall start the SecurityDelayTimer with the value configured in DcmDspSecurityDelayTime for the SecurityLevel which was requested in the failed request, send a negative response with NRC 0x36 (exceededNumberOfAttempts) and shall not change the Dcm internal security level.

[SWS_Dcm_01150]

[ ]

If Xxx_CompareKey() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the ErrorCode parameter value and shall not increment the attempt counter or change the Dcm internal security level.

[SWS_Dcm_01350]

[ ]

While the SecurityDelayTimer of SecurityLevel is not yet elapsed, the Dcm module shall send a negative response with NRC 0x37 (requiredTimeDelayNotExpired) on a SecurityAccess (0x27) requestSeed subfunction request for that Security Level.

[SWS_Dcm_00659]

[ ]

If Xxx_GetSeed() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the ErrorCode parameter value.

CommunicationControl (0x28) Service

[SWS_Dcm_00511]

[ ]

The Dcm module shall implement the CommunicationControl (service 0x28) of the Unified Diagnostic Services.

[SWS_Dcm_00512]

[ ]

On invocation of the sent confirmation function of the UDS Service CommunicationControl (0x28) from DSD with the subnet parameter of the request equal to 0x00, the Dcm shall do for each NetworkHandle (see DcmDspAllComMChannelRef) which is configured in DcmDspComControlAllChannel:

trigger the mode switch Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to the mode corresponding the communicationType and controlType parameter from the CommunicationControl request.

call the Api BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType and Dcm_CommunicationModeType corresponding to the communicationType and controlType parameter from the CommunicationControl request (see Dcm_CommunicationModeType definition).

[SWS_Dcm_00785]

[ ]

On invocation of the sent confirmation function of the UDS Service CommunicationControl (0x28) from DSD with the subnet parameter of the request equal to 0x0F(CommunicationControl on the network which request is received on), the Dcm shall do for the NetworkHandle (see DcmDslProtocolComMChannelRef) of the current received DcmDslProtocolRxPduRef:

trigger the mode switch Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to the mode corresponding to the communicationType and controlType parameter from the CommunicationControl request.

call the Api BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType and Dcm_CommunicationModeType corresponding to the communicationType and controlType parameter from the CommunicationControl request (see Dcm_CommunicationModeType definition)

[SWS_Dcm_00786]

[ ]

On invocation of the sent confirmation function of the UDS Service CommunicationControl (0x28) from DSD with the subnet parameter of the request between 0x01 and 0x0E, the Dcm shall check if the received subnet parameter (see DcmDspSubnetNumber) is supported. In case it is not supported a NegativeResponse code 0x31 shall be sent. In case it is supported the Dcm shall do for the corresponding NetworkHandle (see DcmDspSpecificComMChannelRef) of the received subnet parameter (see DcmDspSubnetNumber):

trigger the mode switch Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to the mode corresponding the communicationType and controlType parameter from the CommunicationControl request.

call the Api BswM_Dcm_CommunicationMode_CurrentState the parameters NetworkHandleType and with Dcm_CommunicationModeType corresponding the communicationType and controlType parameter from the CommunicationControl request (see Dcm_CommunicationModeType definition)

For some use-cases the Dcm may re-enable the CommunicationControl due to external changed mode conditions:

[SWS_Dcm_00753]

[ ]

In case that the referenced ModeRule (see ECUC_Dcm_00943) is not fulfilled anymore for a NetworkHandle which is currently in a state other than DCM_ENABLE_RX_TX_NORM_NM, the Dcm shall:

switch the mode group Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype toDCM_ENABLE_RX_TX_NORM_NM

call BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType set to the corresponding NetworkHandle of the network and RequestedCommunicationMode set to DCM_ENABLE_RX_TX_NORM_NM

[SWS_Dcm_00860]

[ ]

For a NetworkHandle which is currently in a state other than DCM_ENABLE_RX_TX_NORM_NM if the Dcm is transitioning to default session or upon any diagnostic session change where the new session does not support UDS Service CommunicationControl anymore, the Dcm shall:

switch the mode group Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to DCM_ENABLE_RX_TX_NORM_NM

call BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType set to the corresponding NetworkHandle of the network and RequestedCommunicationMode set to DCM_ENABLE_RX_TX_NORM_NM

Note:

the NetworkHandles to be considered are all ComM channels which are referenced from either DcmDspSpecificComMChannelRef, DcmDspAllComMChannelRef or DcmDspComControlSubNodeComMChannelRef.

[SWS_Dcm_01077]

[ ]

If a CommunicationControl Request with the sub-function "enableRxAndDisableTxWithEnhancedAddressInformation" is received, the Dcm shall check the "nodeIdentification-Number" listed as DcmDspComControlSubNodeId and for the referenced network (see DcmDspComControlSubNodeComMChannelRef ), it shall do the followings:

trigger the mode switch Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to the mode corresponding the communicationType and controlType parameter from the CommunicationControl request.

call the Api BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType and Dcm_CommunicationModeType corresponding to the communicationType and controlType parameter from the CommunicationControl request (see Dcm_CommunicationModeType definition).

The analogue controlType enableRxAndDisableTx shall be used with the the following existing Dcm_CommunicationModeType values:

DCM_ENABLE_RX_DISABLE_TX_NORM

DCM_ENABLE_RX_DISABLE_TX_NM

DCM_ENABLE_RX_DISABLE_TX_NORM_NM.

[SWS_Dcm_01078]

[ ]

The Dcm shall trigger a negative response with NRC 0x31 (RequestOutOfRange), if a CommunicationControl Request with the sub-function "enableRxAndDisableTxWithEnhancedAddressInformation" and a "nodeIdentificationNumber" which is not listed as DcmDspComControlSubNodeId is received.

[SWS_Dcm_01079]

[ ]

If a CommunicationControl Request with the sub-function "enableRxAndTxWithEnhancedAddressInformation" is received, the Dcm shall check the "nodeIdentification-Number" listed as DcmDspComControlSubNodeId and for the referenced network (see DcmDspComControlSubNodeComMChannelRef ) it shall do the followings:

trigger the mode switch Dcm_CommunicationControl_<Network> ModeDeclarationGroupPrototype to the mode corresponding the communicationType and controlType parameter from the CommunicationControl request.

call the Api BswM_Dcm_CommunicationMode_CurrentState with the parameters NetworkHandleType and Dcm_CommunicationModeType corresponding to the communicationType and controlType parameter from the CommunicationControl request (see Dcm_CommunicationModeType definition).

The analogue controlType enableRxAndTx shall be used with this the following existing Dcm_CommunicationType values :

DCM_ENABLE_RX_TX_NORM

DCM_ENABLE_RX_TX_NM

DCM_ENABLE_RX_TX_NORM_NM.

[SWS_Dcm_01080]

[ ]

The Dcm shall trigger a negative response with NRC 0x31 (RequestOutOfRange), if a CommunicationControl Request with the sub-function "enableRxAndTxWithEnhancedAddressInformation" and a "nodeIdentification-Number" which is not listed as DcmDspComControlSubNodeId is received.

[SWS_Dcm_01081]

[ ]

If DcmDspComControlSubNodeUsed is set to FALSE the subsystem (DcmDspComControlSubNode) is not available in this configuration.

[SWS_Dcm_01082]

[ ]

If DcmDspComControlSubNodeUsed is set to TRUE the subsystem (DcmDspComControlSubNode) is available in this configuration.

Note :

Condition checks (i.e. NRC 22 checks) on CommunicationType and NetworkType as well as check of CommunicationType support (i.e. NRC 0x31 check for CommunicationType) are not directly supported by the Dcm. Supplier/manufacturer notifications can be used.

Authentication (0x29) Service

The UDS service Authentication (0x29) is used to provide dynamic means to control the access to diagnostic services. Execution of certain diagnostic services might have impact on safety, emissions or the vehicle. Controlling the access to diagnostic services via certificates provide means to control the access to diagnostic services after production. The access to these resources can be limited in time or bound to certain vehicles or ECUs only. AUTOSAR Dcm provides an out of the box solution for authenticated diagnostics with a given semantics of the UDS service Authentication. Even ISO14229-1 [8] leaves more freedom, the Dcm will use only the functionality specified in this chapter. Further interpretations, certificate types or certificate content are out of scope of the AUTOSAR Dcm module.

Support of UDS service authentication

[SWS_Dcm_01559]

[RS_Diag_04230]

The Dcm shall implement the UDS service Authentication (0x29) for Subfunctions:

deAuthenticate

verifyCertificateUnidirectional

verifyCertificateBidirectional

proofOfOwnership

authenticationConfiguration

Note:

AUTOSAR Dcm only implements the authentication via PKI certificated exchange. Authentication with challenge-response (ACR) is out of scope of AUTOSAR. If it is required it needs a full custom implementation using existing Dcm callouts for custom service processing.

NRC Handling for UDS service authentication

[SWS_Dcm_01551]

[RS_Diag_04230]

The Dcm shall follow the NRC handling as defined for ISO 14229-1:2018 for UDS service authentication. This includes the NRC codes as well as the order of individual NRC checks.

Authentication configuration

[SWS_Dcm_CONSTR_06091]

[ ]

The presence of a DcmDsdService with DcmDsdSidTabServiceId set to 0x29, requires a configured container DcmDspAuthentication on DcmDsp.

Authentication per connection

[SWS_Dcm_CONSTR_06092]

[ ]

The presence of a DcmDsdService with DcmDsdSidTabServiceId set to 0x29, requires a configured DcmDspAuthenticationConnection per configured connection DcmDslConnection.

One authentication configuration per connection

[SWS_Dcm_CONSTR_06093]

[ ]

Each DcmDspAuthenticationConnection shall refer a different DcmDslMainConnection by the reference in DcmDspAuthenticationConnectionMainConnectionRef.

The Dcm is using the Csm and KeyM for certificate management. Parsing the certificate is a potential time-consuming operation and needs to be executed asynchronous. There are opinions that security shall not reveal any cause of failed authentication and thus have no dedicated NRCs for different certificate failures. To respect this use case the Dcm provides a general security NRC handling.

Use of generic NRC for invalid certificate or content

[SWS_Dcm_01560]

[RS_Diag_04230]

If the mode referenced by DcmDspAuthenticationGeneralNRCModeRuleRef evaluates to true, the Dcm shall send the NRC code given in DcmDspAuthenticationGeneralNRC instead of the specific NRC codes in all situation where a Certificate verification failed - NRC is returned.

Generic NRC configuration requirements

[SWS_Dcm_CONSTR_06094]

[RS_Diag_04230]

If DcmDspAuthenticationGeneralNRCModeRuleRef is configured the parameter DcmDspAuthenticationGeneralNRC shall also be configured.

De-authentication

The de-authenticate sub-function shall be always available if service 0x29 is used. This service set the authentication state to deauthenticated for the diagnostic connection the request was received on.

[SWS_Dcm_CONSTR_06095]

[ ]

The presence of a DcmDsdService with DcmDsdSidTabServiceId set to 0x29, requires a DcmDsdSubService on this DcmDsdService with DcmDsdSubServiceId set to deAuthenticate.

Deauthentication by diagnostic service request

[SWS_Dcm_01561]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to de-authenticate, the Dcm shall set the authentication state to deauthenticated on the connection the Dcm has received that request.

[SWS_Dcm_01565]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with subfunction equal to de-Authenticate, the Dcm shall reply with a positive response having the authenticationReturnParameter set to DeAuthentication successful.

Verify Certificates

Supported communicationConfiguration

[SWS_Dcm_01459]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateUnidirectional or verifyCertificateBidirectional, the Dcm shall reply with an NRC 0x31 (requestOutOfRange) if the communicationConfiguration (COCO) parameter has a value different than 0x00.

The support of a COCO with constant value of 0x00 implies that no session key is supported by the Dcm. Upon receiving an authentication request with sub-function verifyCertificateUniDirectional and the communicationConfiguration (COCO) set to 0x00, the Dcm starts to verify the certificate. This service is implemented on BSW level by intention, to reduce the possible dialects of service 0x29 to what is natively supported by AUTOSAR. The Csm [18] and KeyM [19] modules allow to use different cryptographic methods. It is part of the Dcm strategy to explicitly require that certificates and all kind of access to information inside are handled by the Csm and its configuration. This allows to map different kind of certificates with different levels of security to the Dcm, thus abstracting the certificate complexity from Dcm.

Verify verifyCertificateUnidirectional message length check

[SWS_Dcm_01460]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateUnidirectional, the Dcm shall verify that the message length fits to the size given in the parameters lengthOfCertificateClient and return a NRC 0x13 if the size does not match.

Verify verifyCertificateBidirectional message length check

[SWS_Dcm_01461]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateBidirectional, the Dcm shall verify that the message length fits to the size given in the parameters lengthOfCertificateClient and lengthOfChallengeClient and return a NRC 0x13 if the size does not match. The Dcm uses the lengthOfCertificateClient as offset to calculate the position of lengthOfChallengeClient.

Required configuration for bidirectional authentication

[SWS_Dcm_01462]

[ ]

If the sub-function verifyCertificateBidirectional is configured in the DsdServiceSubFunction for 0x29, the configuration parameters DcmDspAuthenticationECUCertificateRef and DcmDspAuthenticationECUCertificateKeyElementRef are required.

Mandatory certificate data

[SWS_Dcm_01579]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateUnidirectional or verifyCertificateBidirectionaland a lengthOfCertificateClient equal to zero, the Dcm shall respond with NRC 0x13 (incorrectMessageLengthOrInvalidFormat)..

Store certificate in Csm

Certificate validation

[SWS_Dcm_01463]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateUnidirectional or verifyCertificateBidirectional, the Dcm shall use the KeyM API KeyM_SetCertificate to store the client certificate from the service request within the KeyM module. The following parameter values shall be used:

CertificateId = DcmDspAuthenticationConnectionCertificateRef -> KeyMCertificate.KeyMCertificateId

certificateDataPtr.certData = Pointer to certificateClient from Request

certificateDataPtr.certDataLength = lengthOfCertificateClient from Request

Diagnostic certificate configuration is a task that is mainly executed in the Csm and KeyM modules. The Dcm provides an abstraction from these modules and only keeps symbolic references to containers that keep the information. Please take attention while configuring the Csm and KeyM ’in spirit of Dcm certificates’.

Invalid certificate size failure

[SWS_Dcm_01464]

[RS_Diag_04230]

If the API KeyM_SetCertificate returns KEYM_E_SIZE_MISMATCH, the Dcm shall return the NRC 0x13 (incorrectMessageLengthOrInvalidFormat).

Behavior on busy crypto operation

[SWS_Dcm_01465]

[RS_Diag_04230]

If any of the Csm or KeyM APIs called by the Dcm is returning CRYPTO_E_BUSY or KEYM_E_BUSY, the Dcm shall return the NRC 0x21 (busyRepeat).

Csm APIs returning failure code behavior

[SWS_Dcm_01466]

[RS_Diag_04230]

Throughout this chapter the Csm or KeyM are used to process the authentication requests. These APIs have return values for failures. Unless there is no dedicated requirement for a given return value and if the return value is different to E_OK, the Dcm shall return a NRC 0x10 'GeneralReject'.

The cryptographic operations have potential long execution times and are called asynchronously.

Asynchronous certificate operation handling

[SWS_Dcm_01467]

[RS_Diag_04230]

For all asynchronous Csm or KeyM operations, the Dcm shall wait until the callback has been called, indicating a successful job termination. If the result (e.g. KeyM_CertificateStatusType) is E_OK, the Dcm shall continue to process the 0x29 request, if the result is different to E_OK, the Dcm shall skip the further processing and return a negative response with NRC 'GeneralReject'.

Parse and Verify certificate in Csm

Verifying client certificate

[SWS_Dcm_01468]

[RS_Diag_04230]

After the Dcm has set the certificate according to [SWS_Dcm_01463], the Dcm shall verify the certificate by calling KeyM_VerifyCertificate with the following parameters:

CertificateId = DcmDspAuthenticationConnectionCertificateRef -> KeyMMCertificate.KeyMCertificateId

Behavior on failed certificate verification

[SWS_Dcm_01469]

[RS_Diag_04230]

After the Dcm has verified a certificate and KeyM_CertificateStatusType is set to KEYM_E_CERTIFICATE_SIGNATURE_FAIL, the Dcm shall send a negative response with NRC set to 'Certificate verification failed - Invalid Signature'.

Check certificate chain of trust

[SWS_Dcm_01470]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_INVALID_CHAIN_OF_TRUST, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Chain of Trust'.

Check certificate type

[SWS_Dcm_01471]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_INVALID_TYPE, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Type'.

Check certificate format

[SWS_Dcm_01472]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_INVALID_FORMAT, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Format'.

Check certificate format

[SWS_Dcm_01473]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_INVALID_CONTENT, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Scope'.

Note:

While most of the KeyM return values can be mapped 1:1 on UDS NRC values, this does not apply for KEYM_E_CERTIFICATE_INVALID_CONTENT. An invalid content from KeyM indicates that a key element verification has failed. A failed key element verification means that the certificate itself is valid, but the KeyM refuses the certificate as the data does not fit to the server's required value. In UDS this is expressed by 'Certificate verification failed - Invalid Scope'. As result invalid content from KeyM will trigger the NRC invalid scope.

Check certificate format

[SWS_Dcm_01475]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_REVOKED, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Certificate (revoked)'.

Check certificate valid until

[SWS_Dcm_01476]

[RS_Diag_04235]

If the operation started in [SWS_Dcm_01468] returns a result of KEYM_E_CERTIFICATE_VALIDITY_PERIOD_FAIL, the Dcm shall refuse the client certificate and return a negative response with NRC 'Certificate verification failed - Invalid Time Period'.

Providing the server challenge

The Dcm uses the Csm to create a server challenge by returning a random value.

Length of server challenge

[SWS_Dcm_01588]

[RS_Diag_04230]

The Dcm shall create a server challenge with the length configured in DcmDspAuthenticationEcuChallengeLength.

Creating the server challenge

[SWS_Dcm_01493]

[RS_Diag_04230]

After successfully validating the client certificate in [SWS_Dcm_01463], the Dcm shall create a server challenge by using the Csm in the following sequence:

Call of Csm_RandomGenerate with parameters a. jobId : DcmDspAuthenticationRandomJobRef -> CsmJobId

Wait until the asynchronous job has terminated according to [SWS_Dcm_01467].

The API Csm_RandomGenerate requires an initialised random generator. The initialization of the random generator is a task of the system (integrator).

[SWS_Dcm_01621]

[ ]

If calculation of server challenge fails i.e Csm_RandomGenerate returns CRYPTO_E_ENTROPY_EXHAUSTED, the Dcm shall send NRC 0x59 (Challenge calculation failed).

Sending positive response on verifyCertificateUniDirectional

[SWS_Dcm_01503]

[RS_Diag_04230]

If the Dcm has successfully calculated server challenge the Dcm shall send a positive response for the verifyCertificateUniDirectional request with the following parameter values:

authenticationReturnParameter : 'Certificate verified,

Ownership verification necessary'

lengtfOfChallengeServer: length of the challenge generated in [SWS_Dcm_01493]

challengeServer: challenge generated in [SWS_Dcm_01493]

lengthOfEphemeralPublicKeyServer: 0x0000

Processing a diagnostic request verifyCertificateBidirectional will furthermore require the Dcm to send a server certificate and signing the client challenge. Therefore, the following steps are done additionally for verifyCertificateBidirectional.

Signing client challenge

[SWS_Dcm_01504]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateBidirectional, the Dcm shall sign the received client challenge by calling Csm_SignatureGenerate with the following parameter values:

jobId: DcmDspAuthenticationClientChallengeSignJobRef -> CsmJobId

mode: CRYPTO_OPERATIONMODE_SINGLECALL

dataPtr: Pointer to challengeClient in request

dataLength: lengthOfChallengeClient from request

resultPtr: Dcm sided buffer to store the proofOfOwnershipServer

resultLengthPtr: Response data for lengthOfProofOfOwnershipServer

Require asynchronous client challenge signing

[SWS_Dcm_CONSTR_06096]

[RS_Diag_04230]

DcmDspAuthenticationClientChallengeSignJobRef shall be only accepted if the referenced CsmJob itself:

has a CsmProcessingMode set to CRYPTO_PROCESSING_ASYNC

references a CsmPrimitive with an aggregated CsmSignatureGenerate.

Providing the server certificate

[SWS_Dcm_01506]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to verifyCertificateBidirectional, the Dcm shall provide the server certificate in the response. The Dcm shall call KeyM_GetCertificate with the following parameters:

certId: DcmDspAuthenticationECUCertificateRef/KeyMCertificateId

certificateDataPtr: Dcm implementation specific

Server certificate size check

[SWS_Dcm_01507]

[RS_Diag_04230]

If the API KeyM_GetCertificate returns KEYM_E_KEY_CERT_SIZE_MISMATCH (0x04), the Dcm shall return NRC 0x10 (generalReject).

Sending positive response on verifyCertificateBidirectional

[SWS_Dcm_01508]

[RS_Diag_04230]

If the Dcm has successfully calculated server challenge, the server challenge and the server certificate, the Dcm shall send a positive response for the verifyCertificateBidirectional request with the following parameter values:

authenticationReturnParameter: 'Certificate verified, Ownership verification necessary'

lengtfOfChallengeServer: length of the challenge generated in [SWS_Dcm_01493] challengeServer: challenge generated in [SWS_Dcm_01493]

lengthOfCertificateServer: length of the certificated provided in [SWS_Dcm_01506] certificateServer: certificated provided in [SWS_Dcm_01506]

lengthOfProofOfOwnershipServer: length of proof-of-ownership server created in [SWS_Dcm_01504]

proofOfOwnershipServer: proof-of-ownership server created in [SWS_Dcm_01504]

lengthOfEphemeralPublicKeyServer: 0x0000

Proof of ownership client

Sequence check

[SWS_Dcm_01509]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to proofOfOwnership and if on this connection the most recent processed verifyCertificateUnidirectional or verifyCertificateBidirectional service failed or no such sub-function was processed yet, the Dcm shall send the negative response 'requestSequenceError'. The connection shall remain in de-authenticated state.

Proof of ownership message length check

[SWS_Dcm_01510]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to proofOfOwnership, the Dcm shall verify that the message length fits to the size given in the parameters lengthOfProofOfOwnershipClient and lengthOfEphemeralPublicKeyClient and return a NRC 0x13 if the size does not match.

Client proof of ownership verification

[SWS_Dcm_01511]

[RS_Diag_04230]

On reception of an Authentication (0x29) service with sub-function equal to proofOfOwnership, the Dcm shall verify the client's proof of ownership data provide in the request by calling Csm_SignatureVerify with the following in-parameters:

jobId: DcmDspAuthenticationVerifyProofOfOwnerShipClientJobRef -> CsmJob.CsmJobId

mode: set to CRYPTO_OPERATIONMODE_SINGLECALL

dataPtr: challenge generated [SWS_Dcm_01493]

dataLength: length of the challenge generated in [SWS_Dcm_01493]

signaturePtr: proofOfOwnerShipClient from request

signatureLength: lengthOfProofOfOwnerShipClient from request

Require asynchronous signature verification

[SWS_Dcm_CONSTR_06098]

[ ]

DcmDspAuthenticationVerifyProofOfOwnerShipClientJobRef is only valid if the referenced CsmJob itself:

has a CsmProcessingMode set to CRYPTO_PROCESSING_ASYNC

references a CsmPrimitive with an aggregated CsmSignatureVerify.

Failed ownership verification

[SWS_Dcm_01512]

[RS_Diag_04230]

If the result of Csm_SignatureVerify from [SWS_Dcm_01511] is Crypto_VerifyResultType equal to CRYPTO_E_VER_NOT_OK, the Dcm shall send a negative response with NRC 'Ownership verification failed'.

SessionKey support

[SWS_Dcm_01513]

[RS_Diag_04230]

Upon sending a positive response for an authentication request with sub-function equal to proofOfOwnership, the Dcm shall:

set all bytes of lengthOfSessionKeyInfo to 0x00

omit the sessionKeyInfo

Set current role

Update the current role

[SWS_Dcm_01514]

[RS_Diag_04233]

If the proof of ownership verification in [SWS_Dcm_01511] was successful and resulted in CRYPTO_E_VER_OK, the Dcm shall use the value read from the certificate extension DcmDspAuthenticationRoleElementRef as new role for the current authenticated state.

Role size check

[SWS_Dcm_01515]

[RS_Diag_04230]

If the size of the read role information in [SWS_Dcm_01514] is different than the size in DcmDspAuthenticationRoleSize, the Dcm shall send a negative response with NRC 'Certificate verification failed - Invalid Content'.

Set white list

Update the current whitelist

[SWS_Dcm_01516]

[RS_Diag_04232]

If the proof of ownership verification in [SWS_Dcm_01511] was successful and resulted in CRYPTO_E_VER_OK, the Dcm shall use the white list read from the certificate according to [SWS_Dcm_01517] as new white list for the current authenticated state.

White list access

[SWS_Dcm_01517]

[ ]

To read the white list from a certificate, the Dcm shall read all child elements from the referenced DcmDspAuthenticationWhiteListServicesElementRef, DcmDspAuthenticationWhiteListDIDElementRef, DcmDspAuthenticationWhiteListRIDElementRef and DcmDspAuthenticationWhiteListMemorySelectionElementRef certificate data, by repeating calling the sequence of KeyM_CertElementGetFirst and KeyM_CertElementGetNext until no further child element is available. The Dcm shall use the following in parameter values:

certId: DcmDspAuthenticationConnectionCertificateRef -> KeyMCertificate.KeyMCertificateId

certElementId: DcmDspAuthenticationWhiteListMemorySelectionElementRef -> KeyMCertificateElement.KeyMCertificateElementId

White list size check

[SWS_Dcm_01518]

[RS_Diag_04230]

If the size of the read white list information in [SWS_Dcm_01516] is larger than the size in DcmDspAuthenticationWhiteListMemorySelectionMaxSize, the Dcm shall send a negative response with NRC 'Certificate verification failed - Invalid Content'.

Required size for white lists

[SWS_Dcm_CONSTR_06087]

[RS_Diag_04232]

If any of the optional DcmDspAuthenticationWhiteListMemorySelectionElementRef are configured, the corresponding DcmDspAuthenticationWhiteListMemorySelectionMaxSize shall be configured for that white list.

Definition and verification of roles

The roles transmitted inside the certificates are used to assign a tester on one connection one or more roles. A single role itself is presented by a certain bit within the bitfield representation of the role. Within the Dcm there is static role assignment to each diagnostic service. A service can be executed if at least one role (bit) assigned to a service matches a role (bit) in the certificate.

Supported role sizes

[SWS_Dcm_CONSTR_06088]

[RS_Diag_04233]

The parameter DcmDspAuthenticationRoleSize defines the size in bytes used in both, certificates and ECU internal static role configuration. All role parameters (e.g. DcmDspServiceRole) shall have values that would fit in the amount of bytes given by DcmDspAuthenticationRoleSize.

Integer interpretation of roles in certificates

[SWS_Dcm_01521]

[RS_Diag_04234]

The Dcm shall interpret all configured role integer values in the little endian format.

Role verification

[SWS_Dcm_01522]

[RS_Diag_04233]

[RS_Diag_04234]

Upon each role verification, the Dcm shall make a bitwise 'and' operation on the value provided by the role in the certificate for that connection and the role value assigned to the service. The value that is assigned to the service is calculated by setting all the bits referred by each DcmDspAuthenticationRow. If the result is greater than 0, the Dcm shall treat the service as allowed to be executed.

Failed role verification

[SWS_Dcm_01523]

[RS_Diag_04233]

[RS_Diag_04234]

Upon each role verification, the Dcm shall make a bitwise 'and' operation on the role provided in the certificate for that connection and the role assigned to the service. If the result is equal to 0, the Dcm shall stop the processing of that service and send a negative response 'authenticationRequired'.

An example of roles in certificates and services with assigned certificates is given in Figure 7.11. The provided certificate uses 1 byte for roles, with 5 role definitions in. The certificate will grant the tester rights for the roles 'AfterSales' and 'ExtendedUser'. With that certificate, the tester can execute the services that have the corresponding permissions to be executed in that roles. In that example, the service 0x28 and 0x11 01 are both allowed to be executed. The routine with identifier 0x5678 is only allowed to be executed in role 'production', the Dcm will deny the execution with NRC 'authenticationRequired'.

Figure 7.11: Example for roles

Definition and verification of white lists

Besides the use of roles, the certificates can get extended with optional white lists for service execution. This allows the issuer of the certificate to extend the range of allowed services without updating the access lists in the ECU.

The white list is build out of the following elements:

List of allowed services, 1-4 byte each

List of allowed data identifiers (DID) and access information, 3 byte each

List of allowed routine identifiers (RID) and access information, 3 byte each

List of allowed user defined fault memories, 1 byte each

Parsing and access to the different elements of the white lists is done by invoking KeyM_CertElementGetFirst and KeyM_CertElementGetNext according to [SWS_Dcm_01517].

White list for services definition

[SWS_Dcm_01524]

[RS_Diag_04233]

[RS_Diag_04234]

The white list for services is a set of values, each consisting of up to 4 bytes. Each value itself contains the first bytes of a diagnostic service that is allowed be executed.

Example:

In the following example, a white list section within a certificate is shown. It contains 5 additional services that can be executed:

...
SEQUENCE (1 elem)
    SEQUENCE (2 elem)
        OBJECT IDENTIFIER 3.9.3.345.3.1.3453.24.3.9.355.73
    SET (6 elem)
        OCTET STRING (1 byte) 85
        OCTET STRING (2 byte) 1101
        OCTET STRING (3 byte) 22123A
        OCTET STRING (3 byte) 2E123A
        OCTET STRING (4 byte) 310113F4
SEQUENCE (3 elem) ....

This will allow the Dcm to execute:

Service 0x85 (with any sub-subfunction and DTCSettingControlOptionRecord byte)

Service 0x11 01

Read and WriteDataByIdentifier for DID 0x123A

Routine Start for RID 0x13F4

Checks for white lists for services are all done at DSD level. The Dcm checks if the first bytes of a received diagnostic request match the values allowed by the white list. If a white list entry exists where all bytes are matching the first bytes of the request, the service is granted access.

For all other white lists, the Dcm performs the checks at DSP level in the corresponding service processors.

Please note that it is possible to allow a DID execution in two places in the white list: 1) as 3 byte service and 2) as DID in the DID list. The difference is that the service checks only the first 3 bytes of the PDU and will not detect the DID being used in multiple DID or dynamically defined DID requests, while the DID list element is verified in all services requesting the DID.

White list definition for DIDs

[SWS_Dcm_01525]

[RS_Diag_04233]

[RS_Diag_04234]

The white list for DIDs defines the set of data identifiers that are allowed to be read, written and controlled. Each entry shall contain in the first two bytes the DID number and in the third byte the following access definitions:

Bit 0: Read access

Bit1: Write access

Bit2: Control access (by InputOutputControlByIdentifier)

A bit value of 0 means that the operation is forbidden, a bit value of 1 means that the operation is allowed. All not used bits (3-7) shall be set to zero. DID numbers are always in big endian format (MSB first).

Example:

DID read operations are performed from various UDS services. Dcm checks on each DID read the access to that DID.

White list definition for RIDs

[SWS_Dcm_01526]

[RS_Diag_04233]

[RS_Diag_04234]

The white list for RIDs defines the set of routine identifiers that have access to the sub-functions startRoutine, stopRoutine and requestRoutineResult. Each entry shall contain in the first two bytes the RID number and in the third byte the following access definitions:

Bit 0: Access to sub-function ’startRoutine’

Bit1: Access to sub-function ’stopRoutine’

Bit2: Access to sub-function ’requestRoutineResult’

A bit value of 0 means that the sub-function is forbidden, a bit value of 1 means that the sub-function is allowed. All not used bits (3-7) shall be set to zero. RID numbers are always in big endian format (MSB first).

Example:

White list definition for MemorySelection

[SWS_Dcm_01527]

[RS_Diag_04233]

[RS_Diag_04234]

The white list memory selection is used for the UDS service 0x19 with sub-functions 0x17, 0x18 and 0x19. The value in the white list defines the accepted parameter values for MemorySelection in the UDS request.

Transition into authenticated session

Transition into authenticated state

[SWS_Dcm_01528]

[RS_Diag_04230]

If the proof of ownership verification in [SWS_Dcm_01511] was successful and resulted in CRYPTO_E_VER_OK and after the role and white list setting was done, the Dcm shall set the DcmAuthenticationState_{Channel} on that connection into DCM_AUTHENTICATED.

Successful ownership verification

[SWS_Dcm_01529]

[RS_Diag_04230]

If the result of Csm_SignatureVerify from [SWS_Dcm_01511] is Crypto_VerifyResultType equal to CRYPTO_E_VER_OK, the Dcm shall send a positive response with authenticationReturnParameter set to 'Ownership verified, Authentication complete' and providing a size of 0 for lengthOfSessionKeyInfo and no sessionKeyInfo.

Persisting authentication state

[SWS_Dcm_01530]

[RS_Diag_04230]

If the result of Csm_SignatureVerify from [SWS_Dcm_01511] is Crypto_VerifyResultType equal to CRYPTO_E_VER_OK and the mode rule referenced by DcmDspAuthenticationPersistStateModeRuleRef is evaluated to true, the Dcm shall persist the authentication state, role and white list on that connection.

Activation of role and white list

[SWS_Dcm_01531]

[ ]

The Dcm shall consider the role and white list for access control only, if the Dcm is in authenticated state.

Re-entering authenticated state

[SWS_Dcm_01532]

[RS_Diag_04230]

If the Dcm is already in authenticated state while a transition to authentication stated is requested according to [SWS_Dcm_01529], the Dcm shall overwrite the roles and white list and use only the role and white last from the last received certificate.

AuthenticationConfiguration

Providing the authentication configuration

[SWS_Dcm_01533]

[RS_Diag_04230]

If DcmDspAuthentication is configured and an Authentication (0x29) service with subfunction equal to authenticationConfiguration is received, the Dcm shall send a positive response with authenticationReturnParameter set to 'AuthenticationConfiguration APCE'.

ReadDataByPeriodicIdentifier (0x2A) Service

[SWS_Dcm_01613]

[RS_Diag_04215]

The Dcm shall support the UDS service ReadDataByPeriodicIdentfier (0x2A) with all transmissionMode types according to ISO 14229-1:2020 [8].

Read Periodic DID authentication check for statically defined DIDs

[SWS_Dcm_01552]

[RS_Diag_04233]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), the Dcm shall check if the access to all static defined requested DIDs is authenticated and read the data identifiers periodically only if:

a DID read role is configured via DcmDspDidReadRoleRef for that DID and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for each requested DID one entry with read access that matches that DID.

Read Periodic DID authentication check for dynamically defined DIDs

[SWS_Dcm_01553]

[RS_Diag_04233]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), the Dcm shall check if the access to all dynamically defined requested DIDs if the content is based of DIDs or parts of DIDs is authenticated and read the data identifiers periodically only if:

a DID read role is configured via DcmDspDidReadRoleRef for that DID and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for each requested DID one entry with read access that matches that DID.

Session check for ReadDataByPeriodicIdentifier DID

[SWS_Dcm_00721]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), for every requested periodicDIDs, the Dcm module shall check if the periodicDID can be read in the current session (see configuration parameter DcmDspDidReadSessionRef). If none of the periodicDID can be read in the current session, the Dcm module shall send a NRC 0x31 (RequestOutOfRange).

Security level check for ReadDataByPeriodicIdentifier DID

[SWS_Dcm_00722]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), for every requested periodicDIDs, the Dcm module shall check if the periodicDID can be read in the current security level (see configuration parameter DcmDspDidReadSecurityLevelRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

Note:

To evaluate the session and security assignements the Dcm evaluates the configuration that is used for ReadDataByIdentifier, e.g. DcmDspDidReadSessionRef or DcmDspDidReadSecurityLevelRef.

Mode condition check for ReadDataByPeriodicIdentifier DID

[SWS_Dcm_00820]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), for every requested periodicDIDs, the Dcm module shall check if the periodicDID can be read in the current mode condition (see configuration parameter DcmDspDidReadModeRuleRef). If not, the Dcm module shall send the calculated negative response code of the reference DcmModeRule

Checks for DDDIDs in ReadDataByPeriodicIdentifier

[SWS_Dcm_01097]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), if verification has been successfully done ([SWS_Dcm_00721], [SWS_Dcm_00722] and [SWS_Dcm_00820]), and if the request contains one or more dynamically defined DID(s), the Dcm module shall do the session, security and mode dependencies checks for all source data in case the configuration parameter DcmDspDDDIDcheckPerSourceDID is set to TRUE.

Condition check for ReadDataByPeriodicIdentifier DID

[SWS_Dcm_01098]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), for every requested periodicDIDs, the Dcm module shall invoke the ConditionCheckRead operation (or the respective C-Function) if configured. In case of a negative result, the returned ErrorCode shall be used as final negative response code.

Support of dynamic length DIDs

[SWS_Dcm_01099]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A), for every requested periodicDIDs, with a configured dynamic length the Dcm module shall invoke the ReadDataLength operation (or the respective C-Function) to retrieve the length of the periodicDID. This length is valid for each ReadData operation till the periodicDID is removed from the scheduler or updated via a new request. This length shall further be used to check against the UUDT size.

Ensuring maxim number of periodic DIDs

[SWS_Dcm_00843]

[RS_Diag_04215]

On reception of the UDS Service ReadDataByPeriodicIdentifier (0x2A),the Dcm module shall check if the periodicDataIdentifiers requested in a single request do not exceed the configured DcmDspMaxPeriodicDidToRead (maximum length check). Otherwise (in case the number of elements is exceeded) the Dcm module shall send a NRC 0x13 (Incorrect message length or invalid format).

Behavior on unused DIDs

[SWS_Dcm_01096]

[RS_Diag_04215]

If DcmDspDidUsed is set to FALSE, the Dcm shall consider the DID as not supported.

Scheduler PeriodicTransmission

Note:

The periodic response message layout is according to ISO 14229-1:2020 [8]. It contains the periodic data identifier and the data. The service ID and A_PCI byte is not part of the periodic response message.

[SWS_Dcm_01101]

[RS_Diag_04215]

The Dcm shall send all periodic scheduled response by using the configured DcmDslPeriodicConnections.

ISO 14229-1:2020 [8] defines two distinct scheduler types for ReadDataByPeriodicIdentifier. Depending on the scheduler type, the Dcm has different transmission strategies. The used scheduler type of the server is selected by setting DcmDspPeriodicTransmissionSchedulerType to one of the two types.

Support of periodic transmission type 1

[SWS_Dcm_01568]

[RS_Diag_04215]

If DcmDspPeriodicTransmissionSchedulerType is set to SCHEDULER_TYPE1 and the Dcm is set up to send PDIDs, the Dcm shall trigger the transmission of all scheduled PDIDs each time the configured periodic transmission rate elapses.

Transmission of one PDID per available connection

[SWS_Dcm_01569]

[RS_Diag_04215]

If PDID transmission is triggered according to [SWS_Dcm_01568], Dcm shall transmit one PDID per available periodic connection starting with the first PDID in the list of scheduled PDIDs.

Continue in next main function if more PDIDs than available connections

[SWS_Dcm_01570]

[RS_Diag_04215]

If PDID transmission is triggered according to [SWS_Dcm_01568] and more PDIDs are to transmit than the number of available periodic connections, the Dcm shall continue the transmission in the next Dcm main function call. Each time the available periodic connections shall be used.

Overlapping triggers and transmissions

[SWS_Dcm_01571]

[RS_Diag_04215]

If PDID transmission is triggered according to [SWS_Dcm_01568] or [SWS_Dcm_01572] and the next periodic transmission rate trigger occurs before the Dcm has finished sending the scheduled PDIDs according to [SWS_Dcm_01570], the Dcm shall continue to transmit PDIDs according to [SWS_Dcm_01570] and schedule the PDIDs of the new trigger after the last previous PDID has been transmitted.

Support of periodic transmission type 2

[SWS_Dcm_01572]

[RS_Diag_04215]

If DcmDspPeriodicTransmissionSchedulerType is set to SCHEDULER_TYPE2 the Dcm is set up to send PDIDs and the periodic transmission rate for a scheduler elapses, the Dcm shall trigger the transmission of the next scheduled PDIDs on all available periodic connections.

PDID transmission sequence for scheduler type 2

[SWS_Dcm_01573]

[RS_Diag_04215]

For scheduler type 2 transmission of PDIDs within a single elapse of the scheduler, the Dcm shall start to transmit the first configured PDID and continue to transmit consecutively all other configured PDIDs. If the last PDID is transmitted, the Dcm restarts the sequence with the first configured PDID. If a PDID is sent more than once within a single elapse of the scheduler then the PDIDs contents shall be reloaded with the applicable DID / Memory data for every re-transmission.

Continue in next periodic rate scheduler if more PDIDs than available connections

[SWS_Dcm_01574]

[RS_Diag_04215]

If a scheduler type 2 PDID transmission is active according to [SWS_Dcm_01572] and the number of scheduled PDIDs is larger than the number of available periodic connections, the Dcm shall continue to send the next scheduled PDIDs the next time the periodic transmission rate scheduler elapses.

The following example gives an overview about scheduler type 1 and type 2. They use PDIDs starting at 0xF201 and having all PDID data set to zero. The PDIDs are send on CAN 2.0, using the CAN-IDs 0x6A0, 0x6A1.

Example 1: Scheduler Type 1

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 1

NumPDID 2

1017.02 6A0 01 00 00 00 00 00 00 00

2016.97 6A0 02 00 00 00 00 00 00 00

5016.87 6A0 01 00 00 00 00 00 00 00

6016.78 6A0 02 00 00 00 00 00 00 00

9016.67 6A0 01 00 00 00 00 00 00 00

10016.63 6A0 02 00 00 00 00 00 00 00

13016.52 6A0 01 00 00 00 00 00 00 00

14016.46 6A0 02 00 00 00 00 00 00 00

Example 2: Scheduler Type 2

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 1

NumPDID 2

945.01 6A0 01 00 00 00 00 00 00 00

4944.78 6A0 02 00 00 00 00 00 00 00

8944.66 6A0 01 00 00 00 00 00 00 00

12944.49 6A0 02 00 00 00 00 00 00 00

16944.33 6A0 01 00 00 00 00 00 00 00

20944.28 6A0 02 00 00 00 00 00 00 00

24944.01 6A0 01 00 00 00 00 00 00 00

Example 3: Aliasing with Scheduler Type 1

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 1

NumPDID 5

89 6A0 01 00 00 00 00 00 00 00

70 6A0 02 00 00 00 00 00 00 00

59 6A0 03 00 00 00 00 00 00 00

35 6A0 04 00 00 00 00 00 00 00

16 6A0 05 00 00 00 00 00 00 00 <-- Alias (should start over at)

02 6A0 01 00 00 00 00 00 00 00

15 6A0 02 00 00 00 00 00 00 00

03 6A0 03 00 00 00 00 00 00 00

92 6A0 04 00 00 00 00 00 00 00 <-- Alias (should start over at)

82 6A0 05 00 00 00 00 00 00 00

46 6A0 01 00 00 00 00 00 00 00

60 6A0 02 00 00 00 00 00 00 00

47 6A0 03 00 00 00 00 00 00 00 <-- Alias (should start over at)

36 6A0 04 00 00 00 00 00 00 00

27 6A0 05 00 00 00 00 00 00 00

Example 4: Scheduler Type 2

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 1

NumPDID 5

03 6A0 01 00 00 00 00 00 00 00

56 6A0 02 00 00 00 00 00 00 00

13 6A0 03 00 00 00 00 00 00 00

69 6A0 04 00 00 00 00 00 00 00

26 6A0 05 00 00 00 00 00 00 00

78 6A0 01 00 00 00 00 00 00 00

23 6A0 02 00 00 00 00 00 00 00

90 6A0 03 00 00 00 00 00 00 00

45 6A0 04 00 00 00 00 00 00 00

05 6A0 05 00 00 00 00 00 00 00

Example 5: Scheduler 1 with Multiple Periodic Addresses

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 2

NumPDID 5

69 6A0 01 00 00 00 00 00 00 00

73 6A1 02 00 00 00 00 00 00 00

56 6A0 03 00 00 00 00 00 00 00

61 6A1 04 00 00 00 00 00 00 00

44 6A0 05 00 00 00 00 00 00 00

24 6A0 01 00 00 00 00 00 00 00

27 6A1 02 00 00 00 00 00 00 00

08 6A0 03 00 00 00 00 00 00 00

12 6A1 04 00 00 00 00 00 00 00

12 6A0 05 00 00 00 00 00 00 00

90 6A0 01 00 00 00 00 00 00 00

93 6A1 02 00 00 00 00 00 00 00

70 6A0 03 00 00 00 00 00 00 00

73 6A1 04 00 00 00 00 00 00 00

57 6A0 05 00 00 00 00 00 00 00

Example 6: Scheduler 2 with Multiple Periodic Addresses

SchedulerRate: 1000ms

PeriodicRate: 4000ms

NumPeriodicAddr: 2

NumPDID 5

764.64 6A0 01 00 00 00 00 00 00 00

764.69 6A1 02 00 00 00 00 00 00 00

4762.79 6A0 03 00 00 00 00 00 00 00

4762.82 6A1 04 00 00 00 00 00 00 00

8762.35 6A0 05 00 00 00 00 00 00 00

8762.36 6A1 01 00 00 00 00 00 00 00

12762.01 6A0 02 00 00 00 00 00 00 00

12762.04 6A1 03 00 00 00 00 00 00 00

Example 7: Scheduler 2 with 2 Periodic Addresses and 1 PDID

SchedulerRate: 1000ms

PeriodicRate: 1000ms

NumPeriodicAddr: 2

NumPDID 1

19 6A0 01 00 00 00 00 00 00 00

21 6A1 01 00 00 00 00 00 00 00

61 6A0 01 00 00 00 00 00 00 00

68 6A1 01 00 00 00 00 00 00 00

29 6A0 01 00 00 00 00 00 00 00

40 6A1 01 00 00 00 00 00 00 00

26 6A0 01 00 00 00 00 00 00 00

33 6A1 01 00 00 00 00 00 00 00

13 6A0 01 00 00 00 00 00 00 00

19 6A1 01 00 00 00 00 00 00 00

17 6A0 01 00 00 00 00 00 00 00

24 6A1 01 00 00 00 00 00 00 00

75 6A0 01 00 00 00 00 00 00 00

82 6A1 01 00 00 00 00 00 00 00

77 6A0 01 00 00 00 00 00 00 00

91 6A1 01 00 00 00 00 00 00 00

90 6A0 01 00 00 00 00 00 00 00

97 6A1 01 00 00 00 00 00 00 00

09 6A0 01 00 00 00 00 00 00 00

15 6A1 01 00 00 00 00 00 00 00

Require previous confirmation before next transmission

[SWS_Dcm_01103]

[RS_Diag_04215]

The Dcm shall trigger a transmission DcmDslPeriodicTxPduRef only after the DcmDslPeriodicTxConfirmationPduId transmit confirmation for the previously transmitted periodic response is received.

Transmission error behavior

[SWS_Dcm_01104]

[RS_Diag_04215]

In case of a PDID transmission error, the Dcm shall use always the same order of periodicDIDs per client. Transmission errors shall not influence this order, the Dcm shall continue to retry the transmission and start the next PDID only after the PDID was transmitted successfully.

No negative response for periodic DID after positive response

[SWS_Dcm_01105]

[RS_Diag_04215]

After periodicDIDs are started and a positive response was sent, the Dcm shall start to send the periodic DID.

Sending periodic DIDs without further condition checks

[SWS_Dcm_01106]

[RS_Diag_04215]

Each time the counter of a periodicDataIdentifiers elapses, the Dcm shall retrieve the DID data without validating further conditions (i.e. session, security, mode dependencies, ConditionCheckRead and ReadDataLength).

Note:

The rate for a specific transmissionMode is defined as the time between any two consecutive response messages with the same periodicDataIdentifier, when only a single periodicDID is scheduled. If multiple periodicDIDs are scheduled concurrently, the effective period between the same periodicDataIdentifier will vary based upon the following design parameters:

The main function recurrence DcmTaskTime

The number of available periodic connections

The number of periodicDIDs that can be scheduled concurrently (see configuration parameter DcmDspMaxPeriodicDidScheduler).

Connection limitation for fast transmission

[SWS_Dcm_01575]

[RS_Diag_04215]

If DcmDspPeriodicTransmissionMaxPeriodicFastTransmissions is configured, the Dcm shall limit the number of used periodic connections for transmissionMode 'sendAtFastRate' to DcmDspPeriodicTransmissionMaxPeriodicFastTransmissions connections.

Connection limitation for medium transmission

[SWS_Dcm_01576]

[RS_Diag_04215]

If DcmDspPeriodicTransmissionMaxPeriodicMediumTransmissions is configured, the Dcm shall limit the number of used periodic connections for transmissionMode 'sendAtMediumRate' to DcmDspPeriodicTransmissionMaxPeriodicMediumTransmissions connections.

Connection limitation for slow transmission

[SWS_Dcm_01577]

[RS_Diag_04215]

If DcmDspPeriodicTransmissionMaxPeriodicSlowTransmissions is configured, the Dcm shall limit the number of used periodic connections for transmissionMode 'sendAtSlowRate' to DcmDspPeriodicTransmissionMaxPeriodicSlowTransmissions connections.

Connection order for limited transmissions

[SWS_Dcm_01578]

[RS_Diag_04215]

If any of the transmission connection limitations according to [SWS_Dcm_01575], [SWS_Dcm_01576] or [SWS_Dcm_01577] is configured, the Dcm shall select the DcmDslPeriodicConnection in the order of definition. That means that the first transmitted periodic DID shall take the first configured connections and so forth.

Periodic DDDID transmission and session change

[SWS_Dcm_01111]

[RS_Diag_04215]

If DcmDspDDDIDcheckPerSourceDID is set to TRUE upon a session change, the Dcm shall stop any scheduled periodic DDDID, that contains source data not supported in the current session.

Periodic DDDID transmission and security level change

[SWS_Dcm_01112]

[RS_Diag_04215]

If DcmDspDDDIDcheckPerSourceDID is set to TRUE, upon any security level change, the Dcm shall stop any scheduled periodic DDDID that contains source data not supported in the current security level.

Cancel pending read operations

[SWS_Dcm_01115]

[RS_Diag_04215]

Upon stopping the periodical read of a data identifier while a pending asynchronous ReadData operation is still in progress, the Dcm shall cancel the pending read operation by calling ReadData with OpStatus=DCM_CANCEL.

Stop cancels pending transmissions

[SWS_Dcm_01117]

[RS_Diag_04215]

Upon stopping the periodical read of a data identifier, the Dcm shall cancel pending transmissions of that DID.

Finalizing initiated transmissions upon stop

[SWS_Dcm_01118]

[RS_Diag_04215]

Upon stopping the periodical read of a data identifier the Dcm shall finalize already initiated transmissions of that DID.

DynamicallyDefineDataIdentifier (0x2C) Service

[SWS_Dcm_00259]

[ ]

The DSP submodule shall implement the DynamicallyDefineDataIdentifier (service 0x2C, diagnostic data access) of the Unified Diagnostic Services.

The DynamicallyDefineDataIdentifier service is implemented internally in Dcm module.

[SWS_Dcm_00866]

[ ]

If DcmDDDIDStorage configuration parameter is set to FALSE, the Dcm shall initialize all DDDIDs as not present at power-up Dcm_Init).

[SWS_Dcm_00867]

[ ]

If DcmDDDIDStorage configuration parameter is set to TRUE, the Dcm shall restore the DDDID definition from NvM at power-up Dcm_Init).

[SWS_Dcm_00868]

[ ]

If DcmDDDIDStorage configuration parameter is set to TRUE, the Dcm shall trigger the storage of the DDDID definition to NvRam (via NvM_SetRamBlockStatus).

[SWS_Dcm_00646]

[ ]

On reception of service DynamicallyDefineDataIdentifier with subservice defineByIdentifier or defineByMemoryAddress, the Dcm module shall configure this new DID with associated information receive from the diagnostic request: Memory address and memory length or DID source, position and size.

[SWS_Dcm_00861]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), the Dcm module shall check if the DDDID will not exceed the configured parameter value DcmDspDDDIDMaxElements. Otherwise (in case the number of elements will be exceeded) the Dcm module shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00854]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C) with subservice defineByMemoryAddress, the Dcm shall check if the requested AddressAndLengthFormatIdentifier is supported (refer to configuration parameter DcmDspSupportedAddressAndLengthFormatIdentifier), Otherwise the NRC 0x31 (requestOutOfRange) shall be responded. In case the container AddressAndLengthFormatIdentifier is not present, the Dcm shall accept all possible AddressAndLengthFormatIdentifiers.

[SWS_Dcm_00647]

[ ]

On reception of service DynamicallyDefineDataIdentifier with subservice clearDynamicallyDefinedDataIdentifier, the Dcm module shall remove the configuration of this DID.

[SWS_Dcm_00723]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C),the Dcm module shall check if the DDDID can be defined in the current session (see configuration parameter DcmDspDidReadSessionRef). If not, the Dcm module shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00724]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), the Dcm module shall check if the DDDID can be defined in the current security level (see configuration parameter DcmDspDidReadSecurityLevelRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

[SWS_Dcm_00725]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), the Dcm module shall check if the requested Source-DIDs are supported in the current session (see configuration parameter of referenced DID DcmDspDidReadSessionRef)). If not, the Dcm module shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00726]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), the Dcm module shall check if the requested Source-DID or the memoryRange are supported in the current security level (see configuration parameter of referenced DID DcmDspDidReadSecurityLevelRef or memoryRange DcmDspReadMemoryRangeSecurityLevelRef). If not, the Dcm module shall send a NRC 0x33 (Security access denied).

[SWS_Dcm_00821]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), the Dcm module shall check if the requested Source-DID or the memoryRange are supported in the current mode condition (see configuration parameter of referenced DID DcmDspDidReadModeRuleRef or memoryRange DcmDspReadMemoryRangeModeRuleRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

In case of memory address(es), on reception of ReadDataByIdentifier or ReadDataByPeriodicIdentifier request for a dynamically defined DID, the Dcm will use the callout Dcm_ReadMemory for all contained memory addresses to access the data.

[SWS_Dcm_01051]

[ ]

On reception of the UDS Service DynamicallyDefineDataIdentifier (0x2C), if the request message contains different MemoryIdValue compare to the configured values in DcmDspMemoryIdInfo container, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

In case of DID source(s), on reception of ReadDataByIdentifier or ReadDataByPeriodicIdentifier request for a dynamically defined DID, the Dcm will use the configuration of the contained DIDs to read the data.

WriteDataByIdentifier (0x2E) Service

[SWS_Dcm_00255]

[ ]

The Dcm module shall implement the UDS Service WriteDataByIdentifier (0x2E) of the Unified Diagnostic Services.

When using Service 0x2E, the request of the tester contains a 2-byte DID and a dataRecord with the data to be written. The configuration of the Dcm contains a list of supported DIDs and defines for each configured DID:

The 2-byte DID (see configuration parameter DcmDspDidIdentifier)

For every data of the DID:

The function WriteData to be used for this data (see configuration parameters DcmDspDataWriteFnc and DcmDspDataUsePort)

Write UDS DID authentication check

[SWS_Dcm_01496]

[RS_Diag_04233]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm shall check if the write access to the requested DID is authenticated and write the data identifier only if:

for that write DID a role is configured via DcmDspDidWriteRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for the requested DID one entry with write access that matches that DID.

[SWS_Dcm_00467]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm module shall check if the DID is supported (see configuration parameter DcmDspDid and DcmDspDidRange) If not, the Dcm module shall send NRC 0x31 (Request out of range) .

[SWS_Dcm_00562]

[ ]

If a DID is set as unused (DcmDspDidUsed set to FALSE), the Dcm shall consider the DID as not supported (according to [SWS_Dcm_00467])

[SWS_Dcm_00468]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm module shall check if the DID has a Write access configured (see configuration parameter DcmDspDidWrite in DcmDspDidInfo). If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00469]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm module shall check if the DID can be written in the current session (see configuration parameter DcmDspDidWriteSessionRef). If not, the Dcm module shall send a NRC 0x31 (Request Out of Range).

[SWS_Dcm_00470]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm module shall check if the DID can be written in the current security level (see configuration parameter DcmDspDidWriteSecurityLevelRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

[SWS_Dcm_00822]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), the Dcm module shall check if the DID can be written in the current mode condition (see configuration parameter DcmDspDidWriteModeRuleRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

[SWS_Dcm_00473]

[ ]

On reception of the UDS Service WriteDataByIdentifier (0x2E), if all signals (DcmDspDidSignal) of the DID have fixed length (DcmDspDataType is different than UINT8_DYN), the Dcm module shall check if the received data length corresponds to the DID data length (addition of all DcmDspDataByteSize).

[SWS_Dcm_00395]

[ ]

After all verifications (see [SWS_Dcm_00467], [SWS_Dcm_00468], [SWS_Dcm_00469], [SWS_Dcm_00470], [SWS_Dcm_00473] ) the Dcm module shall write all the signals (DcmDspDidSignal) of the DID by either calling the configured function DcmDspDataWriteFnc (if parameter DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY) or the associated WriteData operations (if parameter DcmDspDataUsePort is set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) or the associated SenderReceiver interfaces (if parameter DcmDspDataUsePort is set to USE_DATA_SENDER_RECEIVER or to USE_DATA_SENDER_RECEIVER_AS_SERVICE) with the following parameter values:

Data: the dataRecord form the request

DataLength: the number of bytes in the dataRecord (get from the configuration if the data has fixed length (DcmDspDataType is different than UINT8_DYN) or from the diagnostic request length if the data has dynamic length (DcmDspDataType is set to UINT8_DYN)).

[SWS_Dcm_01433]

[ ]

After all verifications (see [SWS_Dcm_00467], [SWS_Dcm_00468], [SWS_Dcm_00469], [SWS_Dcm_00470], [SWS_Dcm_00473] ) for DID's with DcmDspDidUsePort is set to USE_ATOMIC_SENDER_RECEIVER_- INTERFACE, USE_ATOMIC_SENDER_RECEIVER_INTERFACE_AS_SERVICE or USE_ATOMIC_NV_DATA_INTERFACE, the Dcm module shall write the data by writing the associated sender-receiver or NvDataInterface DataServices_{DID}.

[SWS_Dcm_00541]

[ ]

If the data is configured as a BlockId of the NvRam (parameter DcmDspDataUsePort set to USE_BLOCK_ID), the Dcm shall :

Request NvM_SetBlockLockStatus(<DcmDspDataBlockIdRef>, FALSE), to temporarily unlock the NvM Block (It might be locked by executing this procedure before).

Request NvM_WriteBlock(<DcmDspDataBlockIdRef >, <DataBuffer>) with BlockId corresponding to the configuration parameter DcmDspDataBlockIdRef)

Poll for completion of write request, using NvM_GetErrorStatus()

On success (NVM_REQ_OK), the Dcm shall issue NvM_SetBlockLockStatus(< DcmDspDataBlockIdRef >, TRUE) (to lock the NvM block against further updates from the application) and send a positive response message.

Otherwise (on any NvM failure) the Dcm module shall trigger a negative response with NRC 0x72 (GeneralProgrammingFailure).

Signals with variable datalength

[SWS_Dcm_CONSTR_06039]

[ ]

Only the last signal (DcmDspDidSignal) of a DID can have variable datalength (DcmDspDataType is set to UINT8_DYN).

In other case the Dcm won't be able to split the data from the request.

[SWS_Dcm_00639]

[ ]

To serialize the request message of UDS Service WriteDataByIdentifier request into the required AUTOSAR data types (signed- and unsigned integer), the target endianness configured in DcmDspDataEndianness shall be considered for DcmDspData elements having DcmDspDataUsePort set to USE_DATA_- SENDER_RECEIVER, USE_DATA_SENDER_RECEIVER_AS_SERVICE. In case DcmDspDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

[SWS_Dcm_CONSTR_06018]

[ ]

DcmDspData elements used in service 0x2E shall not have DcmDspDataUsePorts set to USE_ECU_SIGNAL.

Dependency for DcmDspDataWriteFnc

[SWS_Dcm_CONSTR_06073]

[ ]

DcmDspDataWriteFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Note:

The invocation of functions BndM_WriteStart and BndM_WriteFinalize are not part of Dcm Specification. The functions are called via project specific implementation (e.g. CDD).

Atomic BndM write operation

[SWS_Dcm_01582]

[RS_Diag_04243]

After all verifications (see [SWS_Dcm_00467], [SWS_Dcm_00468], [SWS_Dcm_00469], [SWS_Dcm_00470], [SWS_Dcm_00473]) for DIDs with DcmDspDidUsePort is set to USE_ATOMIC_BNDM, the Dcm module shall write the data by writing the data to the associated BlockId from the BndM (DcmDspDidBndMBlockIdRef) using the block specific writing function BndM_WriteBlock_<BlockId.Shortname>.

Not allowed atomic BndM write operation

[SWS_Dcm_01583]

[RS_Diag_04243]

If the Dcm calls BndM_WriteBlock_'BlockId.Shortname' according to [SWS_Dcm_01582] and BndM_WriteBlock_'BlockId.Shortname' returns E_NOT_OK, the Dcm shall return a negative response 0x24 (requestSequenceError).

Note:

The BndM needs to be set into writing mode as a precondition. This is either done by the coding sub-module in Dcm or by a CDD.

Positive response on atomic BndM write operation

[SWS_Dcm_01584]

[RS_Diag_04243]

If the Dcm has triggered an atomic BndM write operation according to [SWS_Dcm_01582], the Dcm shall return a positive response if the write operation of the BndM has called Dcm_BndMWriteBlockFinish with the parameter result set to E_OK.

Negative response on atomic BndM write operation

[SWS_Dcm_01585]

[RS_Diag_04243]

If the Dcm has triggered an atomic BndM write operation according to [SWS_Dcm_01582], the Dcm shall return a negative response 0x72 (generalProgrammingFailure) if the write operation of the BndM has called Dcm_BndMWriteBlockFinish with the parameter result set to E_NOT_OK.

Note:

The Dcm needs to ensure that [SWS_Dcm_00024] requirement is respected while waiting on the job finish callback as specified in [SWS_Dcm_01584] and [SWS_Dcm_01585].

[SWS_Dcm_01586]

[RS_Diag_04243]

If the Dcm is reading or writing a DID with DcmDspDidUsePort set to USE_ATOMIC_BNDM, the Dcm shall transform the dataRecord into the corresponding BndM type. The DID data element structure needs to be compatible to the referenced ImplementationDataType of the BndMBlockDescriptor. For each DID data element a corresponding sub-element shall exist in the ImplementationDataType with the same shortname and the basetypes shall be compatible.

Consistency of BndM Block configuration

[SWS_Dcm_CONSTR_06099]

[ ]

If a DcmDspDid has DcmDspDidUsePort set to USE_ATOMIC_BNDM, the parameter DcmDspDidBndMBlockIdRef shall be present.

InputOutputControlByIdentifier (0x2F) Service

[SWS_Dcm_00256]

[RS_Diag_04218]

The Dcm module shall implement the UDS Service InputOutputControlByIdentifier (0x2F).

When using Service 0x2F, the request of the tester contains a 2-byte DID.

The configuration of the Dcm contains a list of supported DID's. For each DID, the Dcm configuration specifies:

The 2-bytes DID (see configuration parameter DcmDspDidIdentifier)

For every data of the DID :

The function Xxx_ReturnControlToECU() for this data (see configuration parameters DcmDspDataReturnControlToEcuFnc and DcmDspDataUsePort)

The function Xxx_ResetToDefault() for this data (see configuration parameters DcmDspDataResetToDefaultFnc and DcmDspDataUsePort)

The function Xxx_FreezeCurrentState() for this DID (see configuration parameters DcmDspDataFreezeCurrentStateFnc and DcmDspDataUsePort)

The function Xxx_ShortTermAdjustment() for this DID (see configuration parameters DcmDspDataShortTermAdjustmentFnc and DcmDspDataUsePort)

The sizes of the control record used in the function Xxx_ShortTermAdjustment() (see configuration parameter and DcmDspDataByteSize)

[SWS_Dcm_00579]

[RS_Diag_04218]

The Dcm shall support InputOutputControlParameter definitions according to Table 7.23.

Table 7.23: InputOutputControlParameter definitions

IOControl DID authentication check

[SWS_Dcm_01554]

[RS_Diag_04218]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm shall check if the control access to the requested DID is authenticated and control the IO only if:

for that IO control a role is configured via DcmDspDidControlRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has for the requested DID one entry with control access that matches that DID.

According to [SWS_Dcm_01522] the authentication checks are only executed if DcmDspAuthentication is configured. In case of a failed authentication the NRC handling is according to [SWS_Dcm_01544] and [SWS_Dcm_01551] applies.

[SWS_Dcm_00563]

[RS_Diag_04218]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm module shall check if the DID is supported (see configuration parameter DcmDspDid) If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00564]

[RS_Diag_04218]

If a DID is set as unused (DcmDspDidUsed set to FALSE), the Dcm shall consider the DID as not supported (according to [SWS_Dcm_00563])

[SWS_Dcm_00565]

[RS_Diag_04218]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm module shall check if the DID has a Control access configured (see configuration parameter DcmDspDidControl in DcmDspDidInfo). If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00566]

[ ]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm module shall check if the DID can be control in the current session (see configuration parameter DcmDspDidControlSessionRef). If not, the Dcm module shall send a NRC 0x31 (Request Out of Range).

[SWS_Dcm_00567]

[ ]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm module shall check if the DID can be control in the current security level (see configuration parameter DcmDspDidControlSecurityLevelRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

[SWS_Dcm_00823]

[ ]

On reception of the UDS Service InputOutputControlByIdentifier (0x2F), the Dcm module shall check if the DID can be control in the current mode condition (see configuration parameter DcmDspDidControlModeRuleRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

CEMR on SR interface for DIDs with no CEMR in the UDS request

[SWS_Dcm_01600]

[RS_Diag_04218]

If the IOC DID has no CEMR in the UDS request message, the Dcm shall use a Dcm_Cemr_Type that has a bit for each DcmDspData of the DID on the interface IOControlRequest that has each bit set to 1.

[SWS_Dcm_00580]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) , if all verifications have been successfully done (see [SWS_Dcm_00563], [SWS_Dcm_00565], [SWS_Dcm_00566], [SWS_Dcm_00567] ) and if the data is configured as a "ECU signal" of the IoHwAb (parameter DcmDspDataUsePort), the Dcm shall call the Api IoHwAb_Dcm_<symbolic name of ECU signal (parameter DcmDspDataEcuSignal)>() with InputOutputControlParameter for the 'action' parameter and in case of InputOutputControlParameter is set to 'shortTermAdjustment' the signal value for the "signal" parameter. In this case the requirements [SWS_Dcm_00396], [SWS_Dcm_00397], [SWS_Dcm_00398] and [SWS_Dcm_00399] doesn't apply.

[SWS_Dcm_00581]

[RS_Diag_04218]

In case of more than one supported I/O signal per DataIdentifier and the configuration parameter DcmDspDidControlMask is set to DCM_CONTROLMASK_INTERNAL, the Dcm shall internally consider the parameter controlEnableMaskRecord and control only the included signals in the request message.

[SWS_Dcm_CONSTR_06051]

[ ]

The configuration parameter DcmDspDidControlMaskSize shall be only present if DcmDspDidControlMask is equal to DCM_CONTROLMASK_EXTERNAL or DCM_CONTROLMASK_INTERNAL.

[SWS_Dcm_01273]

[RS_Diag_04218]

If the configuration parameter DcmDspDidControlMask is set to DCM_CONTROLMASK_EXTERNAL or DCM_CONTROLMASK_INTERNAL, or the element used in service 0x2F is configured to have an atomic S/R interface, the Dcm shall reject requests without included control enable mask record with the NRC 0x13 (incorrectMessageLengthOrInvalidFormat).

[SWS_Dcm_01274]

[RS_Diag_04218]

If the configuration parameter DcmDspDidControlMask is set to DCM_CONTROLMASK_NO, the Dcm shall reject request with included control enable mask record with the NRC 0x13 (incorrectMessageLengthOrInvalidFormat).

Sender-receiver communication for IOControls is limited to atomic S/R interfaces

[SWS_Dcm_CONSTR_06084]

[RS_Diag_04218]

If a DID has a configured DcmDspDidUsePort = USE_DATA_ELEMENT_SPECIFIC_INTERFACES, the possible values of DcmDspDataUsePort are limited to non S/R interfaces.

Atomic S/R for IOControls are limited to non-NV interfaces

[SWS_Dcm_CONSTR_06085]

[RS_Diag_04218]

If a DID has a configured DcmDspDidControl, the possible values of DcmDspDidUsePort are limited to atomic S/R interface and USE_DATA_ELEMENT_- SPECIFIC_INTERFACES.

Signals for DIDs with Atomic S/R are not shared with other DIDs

[SWS_Dcm_CONSTR_06086]

[RS_Diag_04218]

If a DcmDspDid is configured to have an atomic S/R interface, all DcmDspDataElements referenced by this DID shall be referenced only from this DID.

[SWS_Dcm_CONSTR_06050]

[ ]

If a DcmDspDid is used in service 0x2F and is configured to have an atomic S/R interface, the DcmDspDidControlMask shall be set to DCM_CONTROLMASK_EXTERNAL and the parameter DcmDspDidControlMaskSize shall be present with a value greater than zero.

Mapping of internal ControlEnableMaskRecord to DID data elements

[SWS_Dcm_00680]

[RS_Diag_04218]

If DcmDspDidControlMask is set to DCM_CONTROLMASK_INTERNAL,the ControlEnableMaskRecord shall be mapped to the DID data elements by applying the following mapping :

The most significant bit of the first byte of the ControlEnableMask shall correspond to the first DID data element

The second most significant bit of the first byte of the ControlEnableMask shall correspond to the second DID data element and continuing on in this fashion utilizing as many ControlEnableMask bytes as necessary to map all DID data elements.

The controlEnableMaskRecord is only present, if the DataIdentifer supports more than one signal.

The Dcm supports atomic S/R interfaces activated by the configuration DcmDspDidUsePort set to USE_ATOMIC_SENDER_RECEIVER_INTERFACE or USE_- ATOMIC_SENDER_RECEIVER_INTERFACE_AS_SERVICE. In the text and requirements of this chapter the term 'atomic S/R interface' for IO control means that the IO controlled DID is configured to one of the two choices.

The service use case [TPS_SWCT_01654] and the [constr_1679] limits the S/R interfaces used for IOControl to explicit S/R communication. In implicit communication is not supported by the Dcm.

IOControl General execution sequence

[SWS_Dcm_01434]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) the Dcm shall first execute the service verifications according to [SWS_Dcm_00563], [SWS_Dcm_00565], [SWS_Dcm_00566], [SWS_Dcm_00567] and on successful passing the verifications start the configured service processing.

[SWS_Dcm_00396]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) with inputOutputControlParameter equal to returnControlToEcu, the Dcm module shall invoke all impacted configured function of the controlEnableMaskRecord (if parameter DcmDspDataUsePort set to USE_DATA_- SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataReturnControlToEcuFnc). Alternatively call all the associated ReturnControlToECU operations (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) for every data of the DID received in the request.

[SWS_Dcm_00397]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) with inputOutputControlParameter equal to resetToDefault, the Dcm module shall invoke all impacted configured function of the controlEnableMaskRecord (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_- SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataResetToDefaultFnc). Alternatively call all the associated ResetToDefault operations (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) for every data of the DID received in the request.

[SWS_Dcm_00398]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) with inputOutputControlParameter equal to freezeCurrentState, the Dcm module shall invoke all impacted configured function of the controlEnableMaskRecord (if parameter DcmDspDataUsePort set to USE_DATA_- SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataFreezeCurrentStateFnc). Alternatively call all the associated FreezeCurrentState operations (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) for every data of the DID received in the request.

[SWS_Dcm_00399]

[RS_Diag_04218]

On reception of a request for UDS Service InputOutputControlByIdentifier (0x2F) with inputOutputControlParameter equal to shortTermAdjustment, the Dcm module shall invoke all impacted configured function of the controlEnableMaskRecord (if parameter DcmDspDataUsePort set to USE_DATA_- SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY; see configuration parameter DcmDspDataShortTermAdjustmentFnc). Alternatively call all the associated ShortTermAdjustment operations (if parameter DcmDspDataUsePort set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_ SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR) for every data of the DID received in the request.

Cancel active IO controls on session change

[SWS_Dcm_00858]

[RS_Diag_04119]

On any session transition, the Dcm shall stop all active IO controls according to [SWS_Dcm_01435] which are not supported by the new session.

Cancel active IO controls in default sessions

[SWS_Dcm_00628]

[RS_Diag_04119]

On a session transition to default session, the Dcm shall stop all active IO controls according to [SWS_Dcm_01435].

Cancel active IO controls on security level change

[SWS_Dcm_00859]

[RS_Diag_04119]

On any security level change, the Dcm shall stop all active IO controls according to [SWS_Dcm_01435] which are not support by the new security level anymore.

Dcm cancel IO control sequence

[SWS_Dcm_01435]

[RS_Diag_04119]

If the Dcm needs to cancel an active IO control due to [SWS_Dcm_00858], [SWS_Dcm_00628] or [SWS_Dcm_00859], the Dcm shall do the following:

For controlled data elements with DcmDspDataUsePort set to USE_ECU_SIGNAL: call to IoHwAb_Dcm_<symbolic ECU signal name>() with 'action' parameter set to ReturnControlToECU.

For controlled data elements with DcmDspDataUsePort set to USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR: call the C/S interface operation ReturnControlToECU.

For controlled data elements with DcmDspDataUsePort set to USE_DATA_SYNCH_FNC or USE_DATA_ASYNCH_FNC or USE_DATA_ASYNCH_FNC_ERROR or USE_DATA_SYNCH_FNC_PROXY or USE_DATA_ASYNCH_FNC_PROXY: call the configured function Xxx_ReturnControlToECU (see parameter DcmDspDataReturnControlToEcuFnc)

For controlled DIDs with is configured atomic S/R interfaces: update the data element IOOperationRequest with inputOutputControlParameter = 0x00, the controlEnableMask = 0xFFFFFFFF (The size of the mask depends on the parameter DcmDspDidControlMaskSize) and data element underControl = 0x00.

[SWS_Dcm_00640]

[RS_Diag_04218]

To serialize the required AUTOSAR data types (signed- and unsigned integer) from the request message (in case of inputOutputControlParameter is set to 'shortTermAdjustment') / into the response message of UDS Service InputOutputControlByIdentifier responses, the target endianness configured in DcmDspDataEndianness shall be considered for DcmDspData elements having DcmDspDataUsePort set to USE_ECU_SIGNAL. In case DcmDspDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

[SWS_Dcm_00682]

[RS_Diag_04218]

The controlState in the ControlStatusRecord for positive response message of IoControl service shall be retrieved using the associated ReadData operation/function/SenderReceiver after application processing on the IO control request is positively finalized.

Beside the Client/Server interface, the Dcm provides the SenderReceiver interface IOControlRequest_DID. The underControl data element of this interface is calculated by the Dcm with one state bit for each data element identical to the CEMR. Applications can directly derive the active control enable status without the need to maintain internal states.

The bit-mask underControl contains the accumulated status about which data elements of this particular I/O is currently under diagnostic control. The normal operation state could be derived if the value of underControl is set to 0x00 (which is the initial value). Each set bit indicates a data element which is under diagnostic control via FreezeCurrentState, 'ResetToDefault' or 'ShortTermAdjustment'.

Calculation of the underControl data element

[SWS_Dcm_01436]

[RS_Diag_04218]

The Dcm shall calculate the underControl data element of the S/R interface IOControlRequest_{DID}. The underControl is a bitfield of the same size than the CEMR of the controlled DID. Each bit represents the same data element as in the CEMR. A value of 0 indicates, that the corresponding data element is currently not controlled by the Dcm, a value of 1 indicates that it is controlled. The initial value is 0, each control request for a data element with inputOutputControlParameter equal to ResetToDefault, FreezeCurrentState or ShortTermAdjustment will set the corresponding bit value to 1, and each control request with inputOutputControlParameter set to ReturnControlToECU will set the bit value to 0.

With each I/O Control request a command IOOperationRequest is provided to the application to update the input or the respective output. IOOperationRequest contains the inputOutputControlParameter, the controlEnableMask and in case of ShortTermAdjustment the controlState.

To identify that previous operation has finished (e.g Write IOControlRequest_{DID}), the user can use the update flag mechanism from the RTE.

The application needs to update their output values and finalizes the request with the response message IOOperationRequest to the Dcm. The possible values are:

0x00 positive response (similar to E_OK)

0x10 generalReject

0x21 busyRepeatRequest

0x22 conditionsNotCorrect

0x26 FailurePreventsExecutionOfRequestedAction

0x31 requestOutOfRange

0x78 ResponsePending (similar to E_PENDING)

Based on the write trigger of the SW-C to IOControlResponse_{DID}.IOOperationResponse, the Dcm will:

wait for final processing (0x78)

send a positive response message (0x00)

send a negative response message (all other values, except 0xFF)

Figure 7.12: IO-Control with Sender/Receiver interfaces

inputOutputControlParameter idle state

[SWS_Dcm_01437]

[RS_Diag_04218]

The inputOutputControlParameter of data element of IOOperationRequest from S/R interface IOControlRequest_{DID} shall have an initial value of 0xFF. This value indicates the application, that the Dcm is currently not processing an UDS service to control this DID.

inputOutputControlParameter after processing an UDS InputOutputControlByIdentifier (0x2F) service

[SWS_Dcm_01438]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request with inputOutputControlParameter equal to ResetToDefault, FreezeCurrentState or ShortTermAdjustment, the Dcm shall set the inputOutputControlParameter of data element of IOOperationRequest from S/R interface IOControlRequest_{DID} to the idle state 0xFF after the application has set the IOControlResponse_{DID}.IOOperationResponse to 0x00 and before processing other InputOutputControlByIdentifier requests.

Upon the Dcm writes IOOperationRequest of IOControlRequest_{DID} the SWC processes the IO control request. The SWC informs the Dcm about the current processing state by updating IOControlResponse_{DID}.IOOperationResponse.

Positive response based on IOOperationResponse

[SWS_Dcm_01439]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request, it shall reply with a positive response, if the applications set IOControlResponse_{DID}.IOOperationResponse to 0x00.

Negative response based on IOOperationResponse

[SWS_Dcm_01440]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request, it shall reply with a negative response with the NRC IOControlResponse_{DID}.IOOperationResponse, if the applications set IOControlResponse_{DID}.IOOperationResponse a value different to 0x00 and 0x78.

RCRRP based on IOOperationResponse

[SWS_Dcm_01441]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request and the IOControlResponse_{DID}.IOOperationResponse has a value of 0x78, the Dcm shall wait until the IOControlResponse_{DID}.IOOperationResponse gets a value different to 0x78 and send RCRRP according to [SWS_Dcm_00024].

Note:

The use of the RTE functionality "IsUpdated" is a possible mechanism for the Dcm to detect a write from SW-C to the S/R data element.

Common action for all inputOutputControlParameter operations with atomic S/R

[SWS_Dcm_01275]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request for a DID configured atomic S/R interface, the Dcm module shall update in the IOControlRequest_{DID} the data element IOOperationRequest with

controlEnableMask = controlEnableMaskRecord of the request message

inputOutputControlParameter = inputOutputControlParameter from the request message

The value 0xFF of the inputOutputControlParameter of the command IOOperationRequest is the 'idle' state. The values 0x00 (ReturnControlToECU), 0x01 (ResetToDefault), 0x02 (FreezeCurrentState) or 0x03 (ShortTermAdjustment) start the request processing and include the control option inputOutputControlParameter, controlEnableMask and controlState (for ShortTermAdjustment only).

Additional action for InputOutputControl operations for ShortTermAdjustment with atomic S/R

[SWS_Dcm_01277]

[RS_Diag_04218]

If the Dcm is processing an InputOutputControlByIdentifier request with inputOutputControlParameter equal to ShortTermAdjustment for a DID with configured atomic S/R interface, in addition to [SWS_Dcm_01275] the Dcm module shall update in the IOControlRequest_{DID} the data element controlState with content of the controlState from the request message.

Note:

The controlState is a separate data elment that it can be optionally processed by a data transformer to transform the byte stream into a composite type (see Figure 7.12: IO-Control with Sender/Receiver interfaces).

An example of the Dcm S/R interaction is given in Figure 9.22, Figure 9.23 and Figure 9.24. For ReturnControlToECU the data from the request is provided to the application, the Dcm will continue to finalize the request after writing the data into the S/R ports. All other sub-functions will wait for the application providing the response 0x00 or an NRC code.

Composite sub elements accessible only by read

[SWS_Dcm_CONSTR_06048]

[ ]

Composite sub elements can only be referred from Read DID i.e. Write and Control DID are not supported.

[SWS_Dcm_CONSTR_06030]

[ ]

The ReturnControlToEcu functionnality is existing if at least one of the following parameters are activated : DcmDspDidFreezeCurrentState in ECUC_Dcm_00624 : or DcmDspDidResetToDefault in ECUC_Dcm_00623 : or DcmDspDidShortTermAdjustment in ECUC_Dcm_00625 : .

Dependency for DcmDspDataFreezeCurrentStateFnc

[SWS_Dcm_CONSTR_06059]

[ ]

DcmDspDataFreezeCurrentStateFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Dependency for DcmDspDataResetToDefaultFnc

[SWS_Dcm_CONSTR_06063]

[ ]

DcmDspDataResetToDefaultFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Dependency for DcmDspDidControlMaskSize

[SWS_Dcm_CONSTR_06064]

[ ]

DcmDspDidControlMaskSize shall be only present if DcmDspDidControlMask is equal to DCM_CONTROLMASK_EXTERNAL or DCM_CONTROLMASK_INTERNAL.

Dependency for DcmDspDidControlMaskBitPosition

[SWS_Dcm_CONSTR_06081]

[ ]

The value configured for DcmDspDidControlMaskBitPosition shall be lower than DcmDspDidControlMaskSize * 8.

Dependency for DcmDspDataReturnControlToEcuFnc

[SWS_Dcm_CONSTR_06065]

[ ]

DcmDspDataReturnControlToEcuFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Dependency for DcmDspDataShortTermAdjustmentFnc

[SWS_Dcm_CONSTR_06066]

[ ]

DcmDspDataShortTermAdjustmentFnc shall be only present if:

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_ERROR or

DcmDspDataUsePort is set to USE_DATA_SYNCH_FNC_PROXY or

DcmDspDataUsePort is set to USE_DATA_ASYNCH_FNC_PROXY

Dependency for DcmDspDidControlMaskSize

[SWS_Dcm_CONSTR_06082]

[ ]

DcmDspDidControlMaskSize larger than 4 shall be only allowed if DcmDspDataUsePort is set to USE_DATA_ASYNCH_CLIENT_SERVER, USE_DATA_- ASYNCH_CLIENT_SERVER_ERROR or USE_DATA_SYNCH_CLIENT_SERVER. Note: ControlEnableMask larger than 32 bits is a very rare use case. Therefore the Dcm supports only C/S interfaces to solve this use case.

RoutineControl (0x31) Service

[SWS_Dcm_00257]

[ ]

The Dcm module shall implement the UDS Service RoutineControl (0x31) for subFunctions startRoutine, stopRoutine and requestsRoutineResults.

A tester can use UDS Service 0x31 to start, stop or obtain the results of a routine identified by a 2-byte routineIdentifier. The Dcm module configuration contains a list of the routineIdentifiers (see configuration parameter DcmDspRoutineIdentifier) supported by the DCM. For each routineIdentifier, the Dcm configuration specifies:

The function Xxx_Start() associated with this routineIdentifier (see configuration parameters DcmDspStartRoutineFnc, DcmDspRoutineUsePort and DcmDspRoutineFncSignature)

List of signal available in the request and in the response (see configuration parameters DcmDspStartRoutineIn and DcmDspStartRoutineOut)

The function Xxx_Stop() associated with this routineIdentifier (see configuration parameters DcmDspStopRoutineFnc, DcmDspRoutineUsePort and DcmDspRoutineFncSignature)

List of signal available in the request and in the response (see configuration parameters DcmDspStopRoutineIn and DcmDspStopRoutineOut)

The function Xxx_RequestResults() associated with this routineIdentifier (see configuration parameters DcmDspRequestRoutineResultsFnc, DcmDspRoutineUsePort and DcmDspRoutineFncSignature)

List of signal available in the request and in the response (see configuration parameters DcmDspRequestRoutineResultsIn and DcmDspRequestRoutineResultsOut)

[SWS_Dcm_01442]

[RS_Diag_04224]

If DcmDspRoutineUsePort is set to true, the Dcm shall call the corresponding operation of the C/S interfaces RoutineServices_RoutineName to process this routine.

A routine handler processes the diagnostic routine control request. The Dcm passes the routineControlOption as input parameters to the routine handler. The routine processes the request and writes the result to the output parameters of the routine handler call. In case of shared Rx and Tx buffer, there are two cases where writing to the output parameters of the routine control can cause overwriting of the input parameters:

a routine control uses arrays as output parameters (call by reference)

a routine control writes to output parameters and returns DCM_E_PENDING. It is called again with DcmOpstatus set to DCM_PENDING. The input parameters are derived from the Rx buffer that was overwritten by the previous write to the output parameters

For efficient memory consumption it is controllable, if the Dcm applies further strategies to separate input and output parameters in those situations.

Input and output consistency during C/S based routine handling

[SWS_Dcm_01580]

[RS_Diag_04224]

If DcmDspRoutineUsePort is set to TRUE and the ClientServerOperation.diagArgIntegrity of that operation is also set to TRUE, the Dcm shall ensure that the routine handler in the C/S interfaces RoutineServices_RoutineName writing to the output parameters will not overwrite the input parameters.

"Routine argument integrity for C/S calls

[SWS_Dcm_01581]

[RS_Diag_04224]

If DcmDspRoutineUsePort is set to true and DcmDspRoutineInterfaceArgumentIntegrity is configured, the Dcm shall create the corresponding operation of the C/S interface RoutineServices_RoutineName with ClientServerOperation.diagArgIntegrity set to DcmDspRoutineInterfaceArgumentIntegrity.

Availability of DcmDspRoutineInterfaceArgumentIntegrity

[SWS_Dcm_CONSTR_06097]

[ ]

DcmDspRoutineInterfaceArgumentIntegrity shall only be available if the corresponding DcmDspRoutine has DcmDspRoutineUsePort is set to true.

[SWS_Dcm_01443]

[RS_Diag_04224]

If DcmDspRoutineUsePort is set to false, the Dcm shall use the configured callout functions for routine operations.

[SWS_Dcm_00568]

[ ]

On reception of the UDS Service RoutineControl (0x31), the Dcm module shall check if the Routine is supported (see configuration parameter DcmDspRoutine) If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00569]

[ ]

If a Routine is set as unused (DcmDspRoutineUsed set to FALSE), the Dcm shall consider the Routine as not supported (according to [SWS_Dcm_00568])

StartRoutine authentication check

[SWS_Dcm_01555]

[RS_Diag_04233]

On reception of the UDS Service RoutineControl (0x31) with sub-function startRoutine, the Dcm shall check if the access to the requested routine identifier is authenticated and process the routine only if:

for this start routine service a role is configured via DcmDspStartRoutineRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has one RID entry with sub-function access set to startRoutine that matches that service and sub-function.

StopRoutine authentication check

[SWS_Dcm_01556]

[RS_Diag_04233]

On reception of the UDS Service RoutineControl (0x31) with sub-function stopRoutine, the Dcm shall check if the access to the requested routine identifier is authenticated and process the routine only if:

for this stop routine service a role is configured via DcmDspStopRoutineRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has one RID entry with sub-function access set to stopRoutine that matches that service and sub-function.

RequestRoutineResult authentication check

[SWS_Dcm_01557]

[RS_Diag_04233]

On reception of the UDS Service RoutineControl (0x31) with sub-function requestRoutineResult, the Dcm shall check if the access to the requested routine identifier is authenticated and process the routine only if:

for this request routine results service a role is configured via DcmDspRequestRoutineResultsRoleRef and the verification according to [SWS_Dcm_01522] was successful or

the active white list on that connection has one RID entry with sub-function access set to requestRoutineResults that matches that service and sub-function.

The service RoutineControl (0x31) is of exotic nature and has both, a sub-function and an identifier. UDS defines a different behavior for this service. Permission checks for session and security are done on identifier level rather than on sub-function level.

Same session and security settings for same routine identifier

[SWS_Dcm_CONSTR_06100]

[ ]

All DcmDspCommonAuthorization that are referenced via DcmDspStartRoutineCommonAuthorizationRef, DcmDspStopRoutineCommonAuthorizationRef or DcmDspRequestRoutineResultsCommonAuthorizationRef from a the same DcmDspRoutine, shall have the same (identical) set of referenced DcmDspCommonAuthorizationSecurityLevelRef and DcmDspCommonAuthorizationSessionRef.

[SWS_Dcm_00570]

[ ]

On reception of the UDS Service RoutineControl (0x31), the Dcm module shall check if the Routine can be executed in the current session (see configuration parameters DcmDspStartRoutineCommonAuthorizationRef, DcmDspStopRoutineCommonAuthorizationRef and DcmDspRequestRoutineResultsCommonAuthorizationRef). If not, the Dcm module shall send a NRC 0x31 (Request Out of Range).

[SWS_Dcm_00571]

[ ]

On reception of the UDS Service RoutineControl (0x31), the Dcm module shall check if the Routine can be executed in the current security level (see configuration parameter DcmDspStartRoutineCommonAuthorizationRef, DcmDspStopRoutineCommonAuthorizationRef and DcmDspRequestRoutineResultsCommonAuthorizationRef). If not, the Dcm module shall send NRC 0x33 (Security access denied).

[SWS_Dcm_00869]

[ ]

On reception of the UDS Service RoutineControl (0x31), the Dcm module shall check if the SubFunction to the corresponding Routine is supported (see existence of configuration container DcmDspStopRoutine for SubFunction 0x02; DcmDspRequestRoutineResults for SubFunction 0x03). If not, the Dcm module shall send NRC 0x12 (SubFunction not supported).

[SWS_Dcm_01169]

[ ]

On reception of the UDS Service RoutineControl (0x31) with SubFunction startRoutine, the Dcm module shall check if the Routine can be executed in the current mode condition (see configuration parameter DcmDspStartRoutineCommonAuthorizationRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

[SWS_Dcm_01170]

[ ]

On reception of the UDS Service RoutineControl (0x31) with SubFunction stopRoutine, the Dcm module shall check if the Routine can be executed in the current mode condition (see configuration parameter DcmDspStopRoutineCommonAuthorizationRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

[SWS_Dcm_01171]

[ ]

On reception of the UDS Service RoutineControl (0x31) with SubFunction requestRoutineResults, the Dcm module shall check if the Routine can be executed in the current mode condition (see configuration parameter DcmDspRequestRoutineResultsCommonAuthorizationRef). If not, the Dcm module shall send the calculated negative response code of the referenced DcmModeRule.

Routines have different input and output parameters depending on the routine configuration (e.g. DcmDspStartRoutineIn for input parameter for the routine start service). The signature of the called routine operations Xxx_Start, Xxx_Stop and Xxx_RequestResults is depending on this configuration. The defined parameters for input and output routine data are optional, and marked in brackets '[]' in the definition in [SWS_Dcm_01203], [SWS_Dcm_01204] and [SWS_Dcm_91013].

[SWS_Dcm_01360]

[ ]

For each configured routine input signal in DcmDspStartRoutineInSignal, DcmDspStopRoutineInSignal or DcmDspRequestRoutineResultsInSignal with a signal type unequal to VARIABLE_LENGTH, the optional parameter 'DcmDspRoutineSignalType dataIn_n' shall be provided in the corresponding operations in [SWS_Dcm_01203], [SWS_Dcm_01204] or [SWS_Dcm_91013].

[SWS_Dcm_01361]

[ ]

For a configured routine input signal in DcmDspStartRoutineInSignal, DcmDspStopRoutineInSignal or DcmDspRequestRoutineResultsInSignal with a signal type equal to VARIABLE_LENGTH the optional parameter const 'uint8 * dataInVar' shall be provided in the corresponding operations in [SWS_Dcm_01203] [SWS_Dcm_01204] or [SWS_Dcm_91013].

[SWS_Dcm_01362]

[ ]

For each configured routine output signal in DcmDspStartRoutineOutSignal, DcmDspStopRoutineOutSignal or DcmDspRequestRoutineResultsOutSignal with a signal type unequal to VARIABLE_LENGTH the optional parameter 'DcmDspRoutineSignalType dataOut_n' shall be provided in the corresponding operations in [SWS_Dcm_01203], [SWS_Dcm_01204] or [SWS_Dcm_91013].

[SWS_Dcm_01363]

[ ]

For a configured routine output signal in DcmDspStartRoutineOutSignal, DcmDspStopRoutineOutSignal or DcmDspRequestRoutineResultsOutSignal with a signal type equal to VARIABLE_LENGTH the optional parameter const 'uint8 * dataOutVar' shall be provided in the corresponding operations in [SWS_Dcm_01203], [SWS_Dcm_01204] or [SWS_Dcm_91013].

[SWS_Dcm_01364]

[ ]

The optional in/out parameter currentDataLength in [SWS_Dcm_01203], [SWS_Dcm_01204] or [SWS_Dcm_91013] is always present if at least one of the routine input signal data or routine output signal data have a signal with routine type 'VARIABLE_LENGTH'.

Note:

The 'currentDataLength' parameter as in/out parameter contains the data length in bytes of the 'dataInVar' while calling the operation and it returns the length in bytes of the 'dataOutVar'. As 'dataInVar' and 'dataOutVar' are optional, 'currentDataLength' is only present if at least one of this optional parameter is used.

[SWS_Dcm_00590]

[ ]

When receiving a request for UDS Service RoutineControl (0x31) if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]), the Dcm module shall split the routineControlOptionRecord received according of the list of input signal configured for this routine ( see configuration parameters DcmDspStartRoutineIn, DcmDspStopRoutineIn, DcmDspRequestRoutineResultsIn)

[SWS_Dcm_01614] DRAFT

[ ]

When receiving a request for UDS Service RoutineControl (0x31) if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]) and DcmDspRoutineFncSignature is set to ROUTINE_FNC_PROXY the Dcm module shall pass the routineControlOptionRecord to the called function and send back the resulting routineStatusRecord via the dataInOut parameter where the currentDataLength denotes the size of the passed routineControlOptionRecord and returned routineStatusRecord.

[SWS_Dcm_00400]

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction startRoutine, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]), the Dcm module shall call the configured Xxx_Start() function passing the dataIn, calculated from routineControlOptionRecord (see [SWS_Dcm_00590]), and the dataOut reference according of the list of output signal configured for this routine ( see configuration parameter DcmDspStartRoutineOut).

[SWS_Dcm_00401]

[ ]

Upon completing [SWS_Dcm_00400], when Xxx_Start() returns E_OK, the Dcm module shall reply with a positive response with the data returned by Xxx_Start() in the dataOut as routineStatusRecord (dataOut are merged according to the list of output signal configured for this routine ( see configuration parameter DcmDspStartRoutineOut)).

[SWS_Dcm_01615] DRAFT

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction startRoutine, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]) and DcmDspRoutineFncSignature is set to ROUTINE_FNC_PROXY, the Dcm module shall call the configured Xxx_Start() function passing the routineControlOptionRecord via (see [SWS_Dcm_01614]) and if Xxx_Start() returned E_OK reply the returned routineStatusRecord with a positive response.

[SWS_Dcm_00402]

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction stopRoutine, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]), the Dcm module shall call the configured Xxx_Stop() function passing the dataIn, calculated from routineControlOptionRecord (see [SWS_Dcm_00590]), and the dataOut reference according of the list of output signal configured for this routine ( see configuration parameter DcmDspStopRoutineOut).

[SWS_Dcm_00403]

[ ]

Upon completing [SWS_Dcm_00402], when Xxx_Stop() returns E_OK, the Dcm module shall reply with a positive response with the data returned by Xxx_Stop()in the dataOut as routineStatusRecord (dataOut are merged according to the list of output signal configured for this routine ( see configuration parameter DcmDspStopRoutineOut)).

[SWS_Dcm_01616] DRAFT

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction stopRoutine, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]) and DcmDspRoutineFncSignature is set to ROUTINE_FNC_PROXY, the Dcm module shall call the configured Xxx_Stop() function passing the routineControlOptionRecord via (see [SWS_Dcm_01614]) and if Xxx_Stop() returned E_OK reply the returned routineStatusRecord with a positive response.

[SWS_Dcm_00404]

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction requestRoutineResults, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]), the Dcm module shall call the configured Xxx_RequestResults() function passing the dataIn, calculated from routineControlOptionRecord (see [SWS_Dcm_00590])and provide the dataOut reference according of the list of output signal configured for this routine ( see configuration parameter DcmDspRequestRoutineResultsOut).

[SWS_Dcm_00405]

[ ]

Upon completing [SWS_Dcm_00404], when Xxx_RequestResults() returns E_OK, the Dcm module shall reply with a positive response with the data returned by Xxx_RequestResults()in the dataOut as routineStatusRecord (dataOut are merged according to the list of output signal configured for this routine ( see configuration parameter DcmDspRequestRoutineResultsOut)).

[SWS_Dcm_01617] DRAFT

[ ]

When receiving a request for UDS Service RoutineControl (0x31) with subfunction requestRoutineResults, if all verifications have been successfully done (see [SWS_Dcm_00568], [SWS_Dcm_00570], [SWS_Dcm_00571]) and DcmDspRoutineFncSignature is set to ROUTINE_FNC_PROXY, the Dcm module shall call the configured Xxx_RequestResults() function passing the routineControlOptionRecord via (see [SWS_Dcm_01614]) and if Xxx_RequestResults() returned E_OK, reply the returned routineStatusRecord with a positive response.

[SWS_Dcm_00641]

[ ]

To serialize the required AUTOSAR data types (signed- and unsigned integer) from the request message / into the response message of UDS Service RoutineControl, the target endianness configured in DcmDspRoutineSignalEndianness shall be considered for DcmDspRoutine signals having set to fixed length ( DcmDspRoutineSignalType set to other value than VARIABLE_LENGTH).

Dependency for DcmDspRoutineSignalEndianness

[SWS_Dcm_CONSTR_06072]

[ ]

In case DcmDspRoutineSignalEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

[SWS_Dcm_01139]

[ ]

The Dcm shall follow the NRC handling for RoutineControlService according to ISO 14229-1 [1].

[SWS_Dcm_01140]

[ ]

On reception of the UDS Service RoutineControl (0x31), the Dcm module shall check the overall length of the request. If length of the request is wrong, the Dcm module shall send NRC 0x13 (Incorrect message length or invalid format) to the tester.

[SWS_Dcm_01141]

[ ]

The Dcm shall call the appropriate routine functions of the SWC after having performed the total length check and the Mode rules, security level and session checks (DcmDspStartRoutineCommonAuthorizationRef, DcmDspStopRoutineCommonAuthorizationRef and DcmDspRequestRoutineResultsCommonAuthorizationRef).

Note:

Subsequent checks have to be performed by the SWC.

[SWS_Dcm_01194]

[ ]

On reception of the UDS Service RoutineControl (0x31), for every requested RID inside the OBD range (E000-E0FF), the Dcm shall implicitly allow subfunction StartRoutine.

[SWS_Dcm_00701]

[ ]

On reception of the UDS Service RoutineControl (0x31), for every requested RID inside the OBD range (E000-E0FF) and usage of UDS interface, the Dcm module shall use the routineInfo byte value from DcmDspRoutineInfoByte in the response to the tester.

[SWS_Dcm_01330]

[ ]

If DcmDspEnableObdMirror is set to true, an explicitly configured RID inside the OBD range (E000-E0FF) shall use the UDS interface.

[SWS_Dcm_01331]

[ ]

If DcmDspEnableObdMirror is set to false, all requests within the OBD RID range shall use the UDS interface.

[SWS_Dcm_01332]

[ ]

On reception of the UDS Service RoutineControl (0x31), for every requested RID inside the OBD range (E000-E0FF), the Dcm module shall handle the RID as defined for OBD Service $08 (see [SWS_Dcm_00418], [SWS_Dcm_00947], [SWS_Dcm_00419], [SWS_Dcm_00420], [SWS_Dcm_00948], [SWS_Dcm_01192]) if DcmDspEnableObdMirror is set to true and RID not explicitly configured.

[SWS_Dcm_01333]

[ ]

On reception of the UDS Service RoutineControl (0x31), for every requested RID inside the OBD range (E000-E0FF) and usage of OBD interface, the Dcm shall use the routineInfo byte value from DcmDspRequestControlInfoByte in the response to the tester.

If DcmDspEnableObdMirror is set to FALSE or the RID is explicitly configured inside the OBD TestId range (E000-E0FF), the access to the OBD data shall be given in the following way:

[SWS_Dcm_01390]

[ ]

On reception of an UDS Service RoutineControl (0x31) request with one or more "availability OBDTestIds" as parameter, the Dcm module shall respond with the corresponding supported (=configured) RIDs.

[SWS_Dcm_01392]

[ ]

On reception of an UDS Service RoutineControl (0x31) request with a OBDTestIds that is not an "availability OBDTestIds", the Dcm module shall invoke the configured Xxx_Start() function.

[SWS_Dcm_01393]

[ ]

As specified in [3, SAE J1979], unused data bytes shall be filled with $00.

[SWS_Dcm_01394]

[ ]

If Xxx_Start() doesn't return E_OK, the Dcm shall return NRC 0x22.

[SWS_Dcm_00668]

[ ]

If the operation Start() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to ErrorCode parameter value.

[SWS_Dcm_00669]

[RS_Diag_04249]

If the operation Start() returns value DCM_E_FORCE_RCRRP, the Dcm module shall start the transmission of NRC 0x78.

[SWS_Dcm_00670]

[ ]

If the operation Stop() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to ErrorCode parameter value.

[SWS_Dcm_00671]

[RS_Diag_04249]

If the operation Stop() returns value DCM_E_FORCE_RCRRP, the Dcm module shall start the transmission of NRC 0x78.

[SWS_Dcm_00672]

[ ]

If the operation RequestResults() returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to ErrorCode parameter value.

[SWS_Dcm_00673]

[RS_Diag_04249]

If the operation RequestResults () returns value DCM_E_FORCE_RCRRP, the Dcm module shall start the transmission of NRC 0x78.

Dependency for DcmDspStartRoutineFnc, DcmDspStopRoutineFnc, DcmDspRequestRoutineResultsFnc, DcmDspStartRoutineConfirmationFnc, DcmDspStopRoutineConfirmationFnc

[SWS_Dcm_CONSTR_06071]

[ ]

The following configuration parameters shall only be present if DcmDspRoutineUsePort is set to FALSE.

DcmDspStartRoutineFnc

DcmDspStopRoutineFnc

DcmDspRequestRoutineResultsFnc

DcmDspStartRoutineConfirmationFnc

DcmDspStopRoutineConfirmationFnc

Tester Present (0x3E) Service

[SWS_Dcm_00251]

[ ]

The Dcm module shall implement the Tester Present (service 0x3E, diagnostic communication and security) of the Unified Diagnostic Services for the subfunction values 0x00 and 0x80.

Skipping authentication check for tester present

[SWS_Dcm_01558]

[RS_Diag_04230]

The Dcm shall process the UDS service 0x3E (TesterPresent) independently from the current authentication state.

This service is used to keep one or multiple servers in a diagnostic session being different than the defaultSession.

WriteMemoryByAddress (0x3D) Service

[SWS_Dcm_00488]

[ ]

The Dcm module shall implement the WriteMemoryByAddress (service 0x3D) of the Unified Diagnostic Services.

This service is used to write data using a physical memory address.

[SWS_Dcm_00855]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), the Dcm shall check if the requested AddressAndLengthFormatIdentifier is supported (refer to configuration parameter DcmDspSupportedAddressAndLengthFormatIdentifier), Otherwise the NRC 0x31 (requestOutOfRange) shall be responded. In case the container AddressAndLengthFormatIdentifier is not present, the Dcm shall accept all possible AddressAndLengthFormatIdentifiers.

[SWS_Dcm_00489]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), the Dcm shall check if the complete memory range to write to (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') is inside the allowed memory ranges (check of DcmDspWriteMemoryRangeLow and DcmDspWriteMemoryRangeHigh parameters for each DcmDspWriteMemoryRangeInfo container or DcmDspWriteMemoryRangeByLabelLow and DcmDspWriteMemoryRangeByLabelHigh parameters for each DcmDspWriteMemoryRangeByLabelInfo container). If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00490]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be written in the current security level (see DcmDspWriteMemoryRangeSecurityLevelRef). If security level is not correct, the Dcm module shall send NRC 0x33 (securityAccessDenied).

[SWS_Dcm_00825]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be written in the current mode condition (see DcmDspWriteMemoryRangeModeRuleRef). If mode condition is not correct, the Dcm module shall send the calculated negative response code of the referenced dcmModeRule.

[SWS_Dcm_00491]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), and after verification of the validity of the request (see [SWS_Dcm_00489] and [SWS_Dcm_00490]) the Dcm module shall call the callout Dcm_WriteMemory.

[SWS_Dcm_01052]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), if the request message contains different MemoryIdValue compare to the configured values in DcmDspMemoryIdInfo container, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01056]

[ ]

The configured ranges of memory address (DcmDspReadMemoryRangeHigh and DcmDspReadMemoryRangeLow or DcmDspReadMemoryRangeByLabelHigh and DcmDspReadMemoryRangeByLabelLow) shall not overlap each other.

[SWS_Dcm_01358]

[ ]

On reception of the UDS Service WriteMemoryByAddress (0x3D), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be written in the current session (see DcmDspWriteMemoryRangeSessionLevelRef). If the session is not correct, the Dcm module shall send NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00643]

[ ]

If the operation Dcm_WriteMemory returns DCM_WRITE_FAILED, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

[SWS_Dcm_00837]

[RS_Diag_04249]

If the call to Dcm_WriteMemory returns DCM_WRITE_FORCE_RCRRP, the Dcm shall invoke the transmit request for RCR-RP (NRC 0x78 transmission) and the Dcm shall not realize further invocation of the operation till RCR-RP is transmitted.

[SWS_Dcm_00838]

[ ]

After transmit confirmation of a RCR-RP transmitted on the context of [SWS_Dcm_00837], the Dcm calls, from Dcm_MainFunction (due to call context), Dcm_WriteMemory again with OpStatus = DCM_FORCE_RCRRP_OK.

ReadMemoryByAddress (0x23) Service

This service is used to read data using a physical memory address.

[SWS_Dcm_00492]

[ ]

The Dcm module shall implement the ReadMemoryByAddress (service 0x23) of the Unified Diagnostic Services.

[SWS_Dcm_00853]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), the Dcm shall check if the requested AddressAndLengthFormatIdentifier is supported (refer to configuration parameter DcmDspSupportedAddressAndLengthFormatIdentifier), Otherwise the NRC 0x31 (requestOutOfRange) shall be responded. In case the container DcmDspAddressAndLengthFormatIdentifier is not present, the Dcm shall accept all possible AddressAndLengthFormatIdentifiers. ).

[SWS_Dcm_00493]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), the Dcm shall check if the complete memory range to read from (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') is inside the allowed memory ranges (check of DcmDspReadMemoryRangeLow and DcmDspReadMemoryRangeHigh parameters for each DcmDspReadMemoryRangeInfo container or DcmDspReadMemoryRangeByLabelLow and DcmDspReadMemoryRangeByLabelHigh parameters for each DcmDspReadMemoryRangeByLabelInfo container). If not, the Dcm module shall send NRC 0x31 (Request out of range).

[SWS_Dcm_00494]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be readen in the current security level (see DcmDspReadMemoryRangeSecurityLevelRef). If security level is not correct, the Dcm module shall send NRC 0x33 (securityAccessDenied).

[SWS_Dcm_00826]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be readen in the current mode condition (see DcmDspReadMemoryRangeModeRuleRef). If mode condition is not correct, the Dcm module shall send calclulated negative response code of the referenced DcmModeRule.

[SWS_Dcm_00495]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), and after verification of the validity of the request (see [SWS_Dcm_00493] and [SWS_Dcm_00494]) the Dcm module shall call the callout Dcm_ReadMemory.

[SWS_Dcm_01053]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), if the request message contains different MemoryIdValue compare to the configured values in DcmDspMemoryIdInfo container, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01158]

[ ]

The configured ranges of memory address (DcmDspReadMemoryRangeHigh and DcmDspReadMemoryRangeLow or DcmDspReadMemoryRangeByLabelHigh and DcmDspReadMemoryRangeByLabelLow) shall not overlap each other.

[SWS_Dcm_01359]

[ ]

On reception of the UDS Service ReadMemoryByAddress (0x23), the Dcm shall check if the complete memory range (from 'memoryAddress' parameter to 'memoryAddress + memorySize -1') can be read in the current session (see DcmDspReadMemoryRangeSessionLevelRef). If the session is not correct, the Dcm module shall send NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_00644]

[ ]

If the operation Dcm_ReadMemory returns DCM_READ_FAILED, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

[SWS_Dcm_00839]

[RS_Diag_04249]

If the call to Dcm_ReadMemory returns DCM_READ_FORCE_RCRRP, the Dcm shall invoke the transmit request for RCR-RP (NRC 0x78 transmission) and the Dcm shall not realize further invocation of the operation till RCR-RP is transmitted.

[SWS_Dcm_00840]

[ ]

After transmit confirmation of a RCR-RP transmitted on the context of [SWS_Dcm_00839], the Dcm calls, from Dcm_MainFunction (due to call context), Dcm_ReadMemory again with OpStatus = DCM_FORCE_RCRRP_OK.

RequestDownload (0x34) Service

This service is used to request the start of a download process.

[SWS_Dcm_00496]

[RS_Diag_04033]

The Dcm module shall implement the RequestDownload (service 0x34) of the Unified Diagnostic Services.

[SWS_Dcm_00856]

[ ]

On reception of the UDS ServiceRequestDownload (0x34), the Dcm shall check if the requested AddressAndLengthFormatIdentifier is supported (refer to configuration parameter DcmDspSupportedAddressAndLengthFormatIdentifier), Otherwise the NRC 0x31 (requestOutOfRange) shall be responded. In case the container AddressAndLengthFormatIdentifier is not present, the Dcm shall accept all possible AddressAndLengthFormatIdentifiers.

[SWS_Dcm_01057]

[ ]

On reception of the UDS ServiceRequestDownload (0x34), if the request message contains different MemoryIdValue compare to the configured values in DcmDspMemoryIdInfo container, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01132]

[ ]

NRC described in Table 7.24 shall be the responsibility of the callout function.

Table 7.24: NRC managed by callout function for service 0x34

Note:

the callout function can, if needed, return also other NRC but the ones above won't be treated by the Dcm module.

Processing request download without RTE

[SWS_Dcm_01591]

[RS_Diag_04033]

If DcmDspMemoryTransferUsePort is set to FALSE, the Dcm shall call Dcm_ProcessRequestDownload to process the request.

[SWS_Dcm_00757]

[ ]

If the operation Dcm_ProcessRequestDownload returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

[SWS_Dcm_01417]

[RS_Diag_04033]

Upon calling Dcm_ProcessRequestDownload, the Dcm shall write the maximum possible buffer size into the BlockLength parameter.

[SWS_Dcm_01418]

[RS_Diag_04033]

If the function call Dcm_ProcessRequestDownload returns a requested buffer length larger than the supported buffer length of the current protocol connection, the Dcm shall report the Det error DCM_E_INTERFACE_BUFFER_OVERFLOW .

For definition of DCM_E_INTERFACE_BUFFER_OVERFLOW see [SWS_Dcm_00040].

[SWS_Dcm_01419]

[RS_Diag_04033]

If the function call Dcm_ProcessRequestDownload returns a requested buffer length smaller or equal than the supported buffer length of the current protocol connection, the Dcm shall return the BlockLength value within the maxNumberOfBlockLength parameter of the positive response.

RequestUpload (0x35) Service

This service is used to request the start of a upload process.

[SWS_Dcm_00499]

[RS_Diag_04033]

The Dcm module shall implement the RequestUpload (service 0x35) of the Unified Diagnostic Services.

[SWS_Dcm_00857]

[ ]

On reception of the UDS RequestUpload (0x35), the Dcm shall check if the requested AddressAndLengthFormatIdentifier is supported (refer to configuration parameter DcmDspSupportedAddressAndLengthFormatIdentifier), Otherwise the NRC 0x31 (requestOutOfRange) shall be responded. In case the container AddressAndLengthFormatIdentifier is not present, the Dcm shall accept all possible AddressAndLengthFormatIdentifiers.

[SWS_Dcm_01055]

[ ]

On reception of the UDS RequestUpload (0x35), if the request message contains different MemoryIdValue compare to the configured values in DcmDspMemoryIdInfo container, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01133]

[ ]

NRC described in Table 7.25 shall be the responsibility of the callout function.

Table 7.25: NRC managed by callout function for service 0x35

Note:

the callout function can, if needed, return also other NRC but the ones above won't be treated by the Dcm module.

Processing request upload without RTE

[SWS_Dcm_01592]

[RS_Diag_04033]

If DcmDspMemoryTransferUsePort is set to FALSE, the Dcm shall call Dcm_ProcessRequestUpload to process the request.

[SWS_Dcm_00758]

[ ]

If the operation Dcm_ProcessRequestUpload returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

[SWS_Dcm_01420]

[RS_Diag_04033]

Upon calling Dcm_ProcessRequestUpload, the Dcm shall write the maximum possible buffer size into the BlockLength parameter.

[SWS_Dcm_01421]

[RS_Diag_04033]

If the function call Dcm_ProcessRequestUpload returns a requested buffer length larger than the supported buffer length of the current protocol connection, the Dcm shall report the Det error DCM_E_INTERFACE_BUFFER_OVERFLOW .

For definition of DCM_E_INTERFACE_BUFFER_OVERFLOW see [SWS_Dcm_01416].

[SWS_Dcm_01422]

[RS_Diag_04033]

If the function call Dcm_ProcessRequestUpload returns a requested buffer length smaller or equal than the supported buffer length of the current protocol connection, the Dcm shall return the BlockLength value within the maxNumberOfBlockLength parameter of the positive response.

TransferData (0x36) Service

This service is used to transfer data during a download or upload process.

[SWS_Dcm_00502]

[RS_Diag_04033]

The Dcm module shall implement the TransferData (service 0x36) of the Unified Diagnostic Services.

To execute the transfer data request, it is mandatory to have a previous received RequestDownload or RequestUpload according to ISO14229-1 [1]. The Dcm will follow this requirements and track internally if such a request was received before the TransferData request. This is relevant to check if a NRC 0x24 sequence error has occurred and to reset the block sequence counter.

Request sequence error check

[SWS_Dcm_01620]

[ ]

The Dcm shall implement the requestSequenceErrorCheck (NRC 0x24) for RequestDownload, RequestUpload and RequestFileTransfer operations according to ISO14229-1 [1].

The Dcm does not track if the data transfer is completed by the memory size parameter. The NRC 0x24 check for this has to be done in the application. This is a deviation to ISO14229-1 [1] where the NRC 0x24 check is done on only one place.

Block sequence counter check

[SWS_Dcm_00645]

[ ]

The Dcm shall realize the block sequence counter error verification according to ISO14229-1 [1] before the Read or Write Data calls are realized and return the NRC 0x73 if the block sequence counter of the request is wrong.

Processing transfer data write without RTE

[SWS_Dcm_00503]

[RS_Diag_04033]

On reception of the UDS Service TransferData (0x36), if a download process is running (RequestDownload service has been previously received), the request format is correct and DcmDspMemoryTransferUsePort is set to FALSE, the Dcm module shall call the callout Dcm_ProcessTransferDataWrite.

Processing transfer data read without RTE

[SWS_Dcm_00504]

[RS_Diag_04033]

On reception of the UDS Service TransferData (0x36), if an upload process is running (RequestUpload service has been previously received),the request format is correct and DcmDspMemoryTransferUsePort is set to FALSE, the Dcm module shall call the callout Dcm_ProcessTransferDataRead.

[SWS_Dcm_01444]

[ ]

On reception of the UDS Service TransferData (0x36), if a file download is running (RequestFileTransfer service has been previously received with 0x01 (AddFile) or 0x03 (ReplaceFile)) and the request format is correct, the Dcm module shall call the callout Dcm_WriteFile().

[SWS_Dcm_01445]

[ ]

On reception of the UDS Service TransferData (0x36), if a file or directory information upload is running (RequestFileTransfer service has been previously received with 0x04 (ReadFile) or 0x05 (ReadDir)) and the request format is correct, the Dcm module shall call the callout Dcm_ReadFileOrDir().

[SWS_Dcm_01173]

[ ]

NRCs described in Table 7.26 shall be the responsibility of the callout function.

Table 7.26: NRC managed by callout function for service 0x36

Note:

the callout function can, if needed, return also other NRCs but the ones above won't be treated by the Dcm module.

RequestTransferExit (0x37) Service

This service is used to terminate a download or upload process.

[SWS_Dcm_00505]

[RS_Diag_04033]

The Dcm module shall implement the RequestTransferExit (service 0x37) of the Unified Diagnostic Services.

[SWS_Dcm_01134]

[ ]

NRC described in Table 7.27 shall be the responsibility of the callout function.

Table 7.27: NRC managed by callout function for service 0x37

Note:

the callout function can, if needed, return also other NRC but the ones above won't be treated by the Dcm module.

Processing transfer exit without RTE

[SWS_Dcm_01593]

[RS_Diag_04033]

If DcmDspMemoryTransferUsePort is set to FALSE, the Dcm shall call Dcm_ProcessRequestTransferExit to process the request.

[SWS_Dcm_00759]

[ ]

If the operation Dcm_ProcessRequestTransferExit returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

Usage of API for RequestTransferExit processing

[SWS_Dcm_01594]

[RS_Diag_04033]

If DcmDspMemoryTransferUsePort is set to false, the Dcm shall use the API Dcm_ProcessRequestTransferExit to process the RequestTransferExit request.

Usage of C/S interface for RequestTransferExit processing

[SWS_Dcm_01595]

[RS_Diag_04033]

If DcmDspMemoryTransferUsePort is set to true, the Dcm shall use the operation ProcessRequestTransferExit of the C/S interface UploadDownloadServices to process the RequestTransferExit request.

Mapping of transferRequestParameter

[SWS_Dcm_01596]

[RS_Diag_04033]

For Dcm_ProcessRequestTransferExit and operation ProcessRequestTransferExit of the C/S interface UploadDownloadServices the Dcm shall use:

the size in bytes of the transferRequestParameterRecord from the request in the parameter transferRequestParameterRecordSize

the transferRequestParameterRecord data of the request in the parameter transferRequestParameterRecord

[SWS_Dcm_01597]

[ ]

For Dcm_ProcessRequestTransferExit and operation ProcessRequestTransferExit of the C/S interface UploadDownloadServices the Dcm shall use the size of the implementation data type Dcm_RequestDataArrayType as in-value for the in/out parameter transferResponseParameterRecordSize.

Mapping of transferResponseParameter to the positive response

[SWS_Dcm_01598]

[RS_Diag_04033]

For Dcm_ProcessRequestTransferExit and operation ProcessRequestTransferExit of the C/S interface UploadDownloadServices the Dcm shall use transferResponseParameterRecordSize bytes of the transferResponseParameterRecord as transferResponseParameterRecord of the positive response.

RequestFileTransfer (0x38) Service

[SWS_Dcm_01083]

[ ]

The Dcm module shall implement the RequestFileTransfer (service 0x38) of the Unified Diagnostic Services.

This service is used to request the start of a file transfer process according to ISO14229-1.

[SWS_Dcm_01446]

[ ]

If the DcmRequestFileTransferUsePort is set to TRUE the Dcm shall use C/S calls of the interface RequestFileTransfer for all RequestFileTransfer related callouts.

[SWS_Dcm_01447]

[ ]

If the DcmRequestFileTransferUsePort is set to FALSE the Dcm shall use C function calls for all RequestFileTransfer related callouts.

[SWS_Dcm_01448]

[ ]

If the fileSizeParameterLength parameter in the RequestFileTransfer request is present and outside the closed interval [0x01..0x08], the Dcm shall send a negative response with NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01449]

[ ]

If the modeOfOperation parameter in the RequestFileTransfer request is not supported (0x00 or greater than 0x05), the Dcm shall send a negative response with NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01450]

[ ]

The Dcm shall process RequestFileTransfer according to [5] and, in case of modeOfOperation equal to 0x01 (AddFile) call XXX_ProcessRequestAddFile after the full length check.

[SWS_Dcm_01451]

[ ]

The Dcm shall process RequestFileTransfer according to [5] and, in case of modeOfOperation equal to 0x02 (DeleteFile) call XXX_ProcessRequestDeleteFile after the full length check.

[SWS_Dcm_01452]

[ ]

The Dcm shall process RequestFileTransfer according to [5] and, in case of modeOfOperation equal to 0x03 (ReplaceFile) call XXX_ProcessRequestReplaceFile after the full length check.

[SWS_Dcm_01453]

[ ]

The Dcm shall process RequestFileTransfer according to [5] and, in case of modeOfOperation equal to 0x04 (ReadFile) call XXX_ProcessRequestReadFile after the full length check.

[SWS_Dcm_01454]

[ ]

The Dcm shall process RequestFileTransfer according to [5] and, in case of modeOfOperation equal to 0x05 (ReadDir) call XXX_ProcessRequestReadDir after the full length check.

[SWS_Dcm_01088]

[ ]

If any of the file transfer operations XXX_ProcessRequest<yyy> returns value E_NOT_OK, the Dcm module shall send a negative response with NRC code equal to the parameter ErrorCode parameter value.

[SWS_Dcm_01455]

[ ]

The Dcm shall use the value configured in DcmRequestFileTransferFileSizeOrDirInfoParameterLength as value sent in fileSizeOrDirInfoParameterLength in the response.

[SWS_Dcm_01090]

[ ]

The Dcm shall use the value configured in DcmRequestFileTransferFileSizeOrDirInfoParameterLength as number of bytes sent in fileSizeUncompressedOrDirInfoLength and fileSizeCompressed in the response.

[SWS_Dcm_01456]

[ ]

The Dcm shall use the value configured in DcmRequestFileTransferLengthFormatIdentifier as value sent in lengthFormatIdentifier in the response.

[SWS_Dcm_01091]

[ ]

The Dcm shall use the value configured in DcmRequestFileTransferLengthFormatIdentifier as number of bytes sent in maxNumberOfBlockLength in the response.

[SWS_Dcm_01457]

[ ]

If the maxNumberOfBlockLength does not fit into the requested lengthFormatIdentifier number of bytes, the Dcm shall send NRC 0x10 (generalReject).

[SWS_Dcm_01458]

[ ]

If the fileSizeUncompressedOrDirInfoLength or fileSizeCompressed do not fit into the requested fileSizeOrDirInfoParameterLength number of bytes, the Dcm shall send NRC 0x10 (generalReject).

ControlDTCSetting (0x85) Service

An external test tool can request an ECU to either disable or enable DTC storage in the ECUs error memory by sending a UDS Service 0x85 request with sub-function 0x01 ("ON") or 0x02 ("OFF").

[SWS_Dcm_00249]

[RS_Diag_04159]

The Dcm module shall implement UDS Service ControlDTCSetting (0x85) to enable or disable the storage of DTCs in the ECUs error memory.

[SWS_Dcm_01399]

[RS_Diag_04159]

If the Dcm receives a ControlDTCSetting (0x85) service with DTCSettingControlOptionRecord != 0xFFFFFF, the Dcm shall send a NRC 0x31 (RequestOutOfRange).

[SWS_Dcm_01063]

[RS_Diag_04115]

On reception of UDS Service 0x85 with subfunction 0x01 (DTCSettingType "ON"), the Dcm shall call Dem_EnableDTCSetting() with ClientId = Client Id for this Dcm instance (see DcmDemClientRef).

[SWS_Dcm_00783]

[ ]

In case of Dem_EnableDTCSetting returns E_OK (see [SWS_Dcm_01063]), the Dcm shall invoke a mode switch of the ModeDeclarationGroupPrototype DcmControlDTCSetting by calling SchM_Switch_<bsnp>_DcmControlDTCSetting (RTE_MODE_DcmControlDTCSetting_ENABLEDTCSETTING).

[SWS_Dcm_00406]

[RS_Diag_04115]

On reception of UDS Service 0x85 with subfunction 0x02 (DTCSettingType "OFF"), the Dcm shall call Dem_DisableDTCSetting() with ClientId = Client Id for this Dcm instance (see DcmDemClientRef).

[SWS_Dcm_00784]

[ ]

In case of Dem_DisableDTCSetting returns E_OK (see [SWS_Dcm_00406] ), the Dcm shall invoke a mode switch of the ModeDeclarationGroupPrototype DcmControlDTCSetting by calling SchM_Switch_<bsnp>_DcmControlDTCSetting (RTE_MODE_DcmControlDTCSetting_DISABLEDTCSETTING).

[SWS_Dcm_00751]

[ ]

In case the DTCSetting is disabled and a transitions to default session or upon any diagnostic session change where the new session does not support UDS Service ControlDTCsetting anymore, the Dcm module shall call Dem_EnableDTCSetting() with the following parameters • ClientId: Client Id for this Dcm instance (see DcmDemClientRef) and switch the mode DcmControlDTCSetting to DCM_ENABLEDTCSETTING.

For some use-cases the Dcm may re-enable the controlDTCsetting due to external changed mode conditions:

[SWS_Dcm_00752]

[ ]

In case the DTCSetting is disabled and at least one referenced arbitrary ModeDeclarationGroupPrototypes (see configuration parameter DcmDspControlDTCSettingReEnableModeRuleRef) for service ControlDTCSetting (0x85) with DTCSettingType "OFF" (0x02) are not fulfilled anymore, the Dcm module shall call Dem_EnableDTCSetting() with the following parameters:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

and switch the mode DcmControlDTCSetting to DCM_ENABLEDTCSETTING

Note:

If at least one ModeDeclarationGroupPrototypes is configured (see configuration parameter DcmDspControlDTCSettingReEnableModeRuleRef) for service ControlDTCSetting (0x85) with DTCSettingType "OFF" (0x02), it is recommended to activate the condition check for the according sub-function 0x02(see configuration parameter DcmDsdSubServiceModeRuleRef).

Note:

This active observation of the referenced mode declaration groups can either be achieved by polling the mode condition in each MainFunction cycle or by attaching to the change notification of mode declaration group (SchM will trigger a BSWEntitiy in Dcm on changes of this mode declaration group).

[SWS_Dcm_00829]

[ ]

If the configuration parameter DcmSupportDTCSettingControlOptionRecord is set to true and the length of DTCSettingControlOptionRecord in the request is different from 3 bytes, the Dcm shall return NRC 0x13 (Incorrect message length or invalid format).

[SWS_Dcm_00852]

[ ]

If the configuration parameter DcmSupportDTCSettingControlOptionRecord is set to false and the request contains any data after the subfunction, the Dcm shall return NRC 0x13 (Incorrect message length or invalid format).

[SWS_Dcm_01564]

[ ]

If the configuration parameter DcmSupportDTCSettingControlOptionRecord is set to false and the request contains any data after the subfunction, the Dcm shall return NRC 0x13 (Incorrect message length or invalid format).

ResponseOnEvent (RoE) (0x86) Service

With the UDS Service ResponseOnEvent (0x86), a tester requests the server to start or stop transmission of responses initiated by a specified server event.

Support of ResponseOnEvent

[SWS_Dcm_01625]

[RS_Diag_04160]

The Dcm shall support the UDS service ResponseOnEvent (0x86) and all subfunctions of this service according to ISO 14229-1:2020 [8].

Not supported storageState bit

[SWS_Dcm_01626]

[RS_Diag_04160]

If DcmDspRoeStoreEventSupport is set to false and a RoE request is received with the storeEvent bit set to 1, the Dcm shall send a NRC 0x31 (requestOutOfRange).

Support of eventWindowTime

[SWS_Dcm_00894]

[RS_Diag_04160]

The Dcm shall support a eventWindowTime set to infiniteTimeToResponse and powerWindowTime according to ISO 14229-1:2020 [8].

DTC status changed trigger

[SWS_Dcm_01627]

[RS_Diag_04160]

The Dcm shall use calls to Dcm_DemTriggerOnDTCStatus() as trigger for changes of a DTC status.

The Dcm leaves it open who is calling the Dcm_DemTriggerOnDTCStatus(). However, the Dcm API is designed to be compatible to the Dem module. If the Dem is used, it is recommended to map one Dem DTC status trigger notification to Dcm_DemTriggerOnDTCStatus().

No onDTCStatusChangedEvents during ClearDiagnosticInformation

[SWS_Dcm_01410]

[RS_Diag_04160]

While the Dcm is processing a ClearDiagnosticInformation request, the Dcm shall ignore the callback Dcm_DemTriggerOnDTCStatus.

Discard serviceToRespondToMessage on transmission errors

[SWS_Dcm_00135]

[RS_Diag_04160]

The Dcm shall discard all serviceToRespondTo messages that could not be send due to transmission errors.

There is not queuing for failed RoE responses for later transmission.

Authentication check for service to respond to

[SWS_Dcm_01534]

[RS_Diag_04230]

On transmission of the service to respond to, the Dcm shall perform the service authentication checks and send a positive response only for services that have granted access to that connection.

ResponseOnEvent scheduler rate

[SWS_Dcm_01628]

[RS_Diag_04160]

The Dcm shall implement the RoE scheduler according to ISO 14229-1:2020 [8] and map the configured scheduler rate DcmDspRoeSchedulerRate to ResponseOnEventSchedulerRate from ISO 14229-1:2020 [8].

Maximum number of changed DIDs per scheduler

[SWS_Dcm_01629]

[RS_Diag_04160]

The Dcm shall provide the maximum number of changed DIDs per RoE scheduler by mapping DcmDspRoeMaxNumChangeOfDataIdentfierEvents to MaxNumChangeOfDataIdentfierEvents from ISO 14229-1:2020 [8].

[SWS_Dcm_CONSTR_06104]

[ ]

DcmDspRoeMaxNumChangeOfDataIdentfierEvents shall be configured, if the Dcm is configured to support service ResponseOnEvent with subfunction onChangeOfDataIdentifier.

Maximum number of comparison of value DIDs per scheduler

[SWS_Dcm_01630]

[RS_Diag_04160]

The Dcm shall provide the maximum number of comparison of DIDs per RoE scheduler by mapping DcmDspRoeMaxNumChangeOfDataIdentfierEvents to MaxNumComparisionOfValueEvents from ISO 14229-1:2020 [8].

[SWS_Dcm_CONSTR_06105]

[ ]

DcmDspRoeMaxNumChangeOfDataIdentfierEvents shall be configured, if the Dcm is configured to support service ResponseOnEvent with subfunction onComparisionOfValues.

Maximum supported DID length

[SWS_Dcm_01631]

[RS_Diag_04160]

The Dcm shall provide the maximum length of a DID as input for a ResponseOnEvent event by mapping DcmDspRoeMaxSupportedDIDLength to MaxSupportedDIDLength from ISO 14229-1:2020 [8].

[SWS_Dcm_CONSTR_06106]

[ ]

DcmDspRoeMaxSupportedDIDLength shall be configured, if the Dcm is configured to support service ResponseOnEvent with subfunction onChangeOfDataIdentifier or onComparisionOfValues.

Maximum number of changed DTCs per scheduler

[SWS_Dcm_01632]

[RS_Diag_04160]

The Dcm shall provide the maximum number of DTC status change events by mapping DcmDspRoeMaxNumberOfStoredDTCStatusChangedEvents to MaxNumberOfStoredDTCStatusChangedEvents from ISO 14229-1:2020 [8].

[SWS_Dcm_CONSTR_06107]

[ ]

DcmDspRoeMaxNumberOfStoredDTCStatusChangedEvents shall be configured, if the Dcm is configured to support the service ResponseOnEvent with subfunction onDTCStatusChange.

LinkControl (0x87) Service

This service is used to gain bus bandwidth for diagnostic purposes.

The Service LinkControl (0x87) is user optional. There are different project specific use cases which are not handled in the default Dcm. One use case is to switch the bandwidth in application an other use case performs an OEM bootloader jump.

Therefore the service LinkControl needs to be implemented project specific as external service (refer to Chapter 8.8 Dcm as Service-Component).

OBD Services

Overview

The following table defines the OBD Services supported by the DCM.

Table 7.28: Support for OBD services in the DCM

General behavior

In many cases, the Dcm protocol allows the bundling of several requests (for example several "PIDs") and the corresponding bundling of the responses. The descriptions of the behavior for the individual services do not explicitly consider this. As the Dcm needs to comply with OBD standard (as is defined through various requirements below), the Dcm might need to repeat the steps defined below to parse a request and assemble a valid response.

In a vehicle there can be 3 different types of OBD ECUs:

Master ECU (one per vehicle)

Primary ECU (several per vehicle)

Dependent / Secondary ECUs (several per vehicle)

From the Basic Software point of view Dependent / Secondary ECUs doesn't need any specific OBD functionality. In Dependent / Secondary ECUs OBD-relevant information will not be stored in the Basic Software (e.g. no direct communication with the scan tool). The respective OBD functionality might be handled in Dependent / Secondary ECUs by a SWC.

The following OBD requirements are only valid for Master and Primary ECUs. If necessary the OBD requirements differentiate between Master and Primary Requirement.

The following table gives an overview about which OBD functionality must be supported in a Master ECU, Primary ECU or Dependent / Secondary ECU:

Table 7.29: Overview about OBD functionality in different OBD ECUs

[SWS_Dcm_00077]

[RS_Diag_04058]

When calling the DEM module for OBD services, the Dcm module shall use the following values for the parameter DTCOrigin: Service $0A uses DEM_DTC_ORIGIN_PERMANENT_MEMORY All other services use DEM_DTC_ORIGIN_OBD_RELEVANT_MEMORY

Service $01 - Request Current Powertrain Diagnostic Data

[SWS_Dcm_00243]

[ ]

The Dcm module shall implement the OBD service $01 (Request Current Powertrain diagnostic Data) in compliance to all provisions of the OBD standard.

Using Service $01, an external test tool can request an emission-related ECU to return PID-values or to return the supported PIDs. OBD reserves certain PIDs for the special purpose of obtaining the list of available PIDs in a certain range. These PIDs are called "availability PIDs" and are $00, $20, $40, $60, $80, $A0, $C0 an $E0.

The Dcm collects the PID information from 1 to n SW-Cs. This applies in particular for PIDs which contain several data values for potentially different sources. Example: PID$83 reports Nox Sensor Data for sensor 1 and sensor 2 in one composed PID which might come from different SW-C.

The Dcm configuration defines the PIDs that are available on the ECU. The Dcm configuration defines for each such PID:

The PID Identifier (see configuration parameter DcmDspPidIdentifier)

Indication of the PID is used or not (for postbuild configuration) (see configuration parameter DcmDspPidUsed)

The size of the PID (see configuration parameter DcmDspPidSize)

The supported information for this PID (see configuration parameter DcmDspPidSupportInfo)

List of data (DcmDspPidData) for the PID with the following configuration for every data

The length of the data associated with the PID (see configuration parameter DcmDspPidDataByteSize)

The position of the data in the PID (see configuration parameter DcmDspPidByteOffset)

The reference to the supported information container (see configuration parameter DcmDspPidDataSupportInfo)

The Xxx_ReadData() function that the Dcm must call to obtain the current value of the data or the name of the port that the Dcm uses to obtain the current value through the RTE from a SW-C (see configuration parameters DcmDspPidDataReadFnc and DcmDspPidDataUsePort)

[SWS_Dcm_00407]

[ ]

On reception of an OBD Service $01 request with only "availability PIDs" as parameter, the Dcm shall respond with the corresponding supported (=configured) PIDs encoded according to the OBD standard.

To obtain the value for a PID, the Dcm uses the configured Xxx_ReadData() functions for every data of the PID. To provide OBD Service $01, the Dcm relies on external functions that allow it to obtain the value of the PIDs. There is one such function per data of every PID that is needed by the DCM.

When using a Xxx_ReadData() function, the Dcm provides a buffer of the correct length, which is filled by the function with the data PID value.

[SWS_Dcm_00408]

[ ]

On reception of an OBD Service $01 request with only PIDs that are not "availability PIDs", the Dcm shall obtain the current value of these PIDs by invoking the configured Xxx_ReadData() functions for every data of the PID and shall return these values as response to Service $01.

[SWS_Dcm_00943]

[ ]

On reception of an OBD Service $01 request with a mixure of "avalibility PIDs" and not "avalibility PIDs", this request shall be ignored by the Dcm.

The entity providing the actual implementation of the Xxx_ReadData() function for a specific signal of a PID might be a SW-C or another basic software module. The origin of the function is not known to the Dcm but is part of the Dcm configuration. Some PIDs are provided by the DEM. These PIDs are also explicitly configured in the Dcm configuration and it is the responsibility of a correct Dcm configuration to make the Xxx_ReadData() function point to the correct function provided by the DEM.

Dependency for DcmDspPidDataReadFnc

[SWS_Dcm_CONSTR_06069]

[ ]

DcmDspPidDataReadFnc shall be only present if DcmDspPidDataUsePort is set to USE_DATA_SYNCH_FNC.

For certain PIDs, the Dem provides the function to obtain the PID value. Which PIDs come from the Dem are part of the Dcm configuration.

Note:

For PIDs where Dem provides the function, DcmDspPidDataUsePort for that PID should be set to USE_DATA_SYNCH_FNC and DcmDspPidDataReadFnc shall point to the function Dem_DcmReadDataOfPID<NN> where <NN> represents the Id of the PID.

The data byte A of the PIDs contain the support status of the subsequent data bytes. Since not all data values might be available due to the particular vehicle configuration (e.g. there is only a Nox-sensor 1 available in the vehicle in the example above), the PID response contains in this data byte A the information about the support status of the following data values. Note, that the PIDs always contain the same number of bytes - even if not all values are really available.

[SWS_Dcm_00621]

[ ]

If a PID contains support information (presence of DcmDspPidDataSupportInfo container) the Dcm shall add the support information in the diagnostic response.

[SWS_Dcm_00622]

[ ]

If a PID contains support information (presence of DcmDspPidDataSupportInfo container) the Dcm shall calculate the support information value according to the available data for this PID: for every DcmDspPidData container existing for this PID, the associated support information bits, referenced in DcmDspPidDataSupportInfo, shall be set to one

The response to the OBD-tester needs to be composed out of the available data values. Data bytes that are not provided by an SW-C need to be replaced with fill-byte to obtain a complete PID contents.

[SWS_Dcm_00623]

[ ]

When responding to OBD Service $01, the Dcm shall put fill-bytes between DcmDspPidData in the PID whenever content bytes are missing in order to fit to the PID size (see configuration parameter DcmDspPidSize).

[SWS_Dcm_00944]

[ ]

The Dcm shall set the fill bytes to 0x00.

Note:

If other fill-bytes than 0x00 are needed by legistlation, the application has to provide the value of the fill-byte.

[SWS_Dcm_00718]

[ ]

To serialize the required AUTOSAR data types (signed- and unsigned integer) into the response message of OBD Service $01 responses the target endianness configured in DcmDspPidDataEndianness shall be considered for DcmDspPidData elements having DcmDspPidDataUsePort set to USE_DATA_SENDER_RECEIVER or USE_DATA_SENDER_RECEIVER_AS_SERVICE. In case DcmDspPidDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

Dependency for DcmDspPidDataEndianness

[SWS_Dcm_CONSTR_06068]

[ ]

In case DcmDspPidDataEndianness is not present, the DcmDspDataDefaultEndianness shall be used instead.

Service $02 - Request Power Train FreezeFrame Data

[SWS_Dcm_00244]

[ ]

The Dcm shall implement OBD Service $02 (Request Power Train FreezeFrame Data) in compliance to all provisions of the OBD standard.

For OBD-relevant FreezeFrames AUTOSAR only supports frame 0, which is the minimum required by legislation.

[SWS_Dcm_00409]

[ ]

The Dcm shall ignore all requests regarding record-numbers that are not 0

[SWS_Dcm_00972]

[ ]

On reception of an OBD Service $02 request with a mixure of "availability PIDs" and not "availability PIDs", this request shall be ignored by the Dcm.

[SWS_Dcm_00973]

[ ]

When responding to OBD Service $02, the Dcm shall put fill-bytes between DcmDspPidData in the PID whenever content bytes are missing in order to fit to the PID size (see configuration parameter DcmDspPidSize).

[SWS_Dcm_00974]

[ ]

The Dcm shall set the fill bytes to 0x00.

Note:

If other fill-bytes than 0x00 are needed by legislation, the application has to provide the value of the fill-byte.

The following sections define how specific PIDs are handled by the Dcm.

Service $02 - PID$02

An external tester can request the DTC that caused a FreezeFrame to be stored by using the Service $02 with the PID value $02.

[SWS_Dcm_00279]

[RS_Diag_04058]

On reception of a request for Service $02 with PID $02, the Dcm shall call Dem_DcmGetDTCOfOBDFreezeFrame() with FrameNumber set to 0x00 to get the DTC number.

The Dem module returns the corresponding DTC. Note that this 2-byte DTC is packed into the 4-byte data returned by the call to Dem_DcmGetDTCOfOBDFreezeFrame (). see Dem specification on how this is done.

[SWS_Dcm_01061]

[ ]

If Dem_DcmGetDTCOfOBDFreezeFrame returns E_NOT_OK, the Dcm shall answer positively with $0000 (indicates no stored freeze frame data).

Service $02 - availability PID

Using Service $02, an external tester may request the supported PIDs for a specific freeze-frame by using the "availability PIDs".

[SWS_Dcm_00284]

[ ]

On reception of a service $02 request with an "availability PID", the Dcm shall respond with the corresponding supported (=configured) PIDs encoded according to the OBD standard.

Service $02 - other PIDs

Using Service $02, an external tester may request the values of specific PIDs in specific FreezeFrames.

[SWS_Dcm_00286]

[ ]

On reception of a service $02 request with a PID that is not an "availability PID" and is not $02, the Dcm shall call Dem_DcmReadDataOfOBDFreezeFrame() for every data of the PID with the following parameter values:

PID = the PID received in the OBD request

DestBuffer = a buffer in which the callee can write the value of the PID

BufSize = the size of the DestBuffer, this must be at least equal to the size needed to store the value of the PID as configured in the DCM

DataElementIndexOfPid = implicit index (from 0 to n) of the DataElement calculated by Dcm according to the order of the DataElement positions in the PID (see parameter DcmDspPidByteOffset)

Note that is not necessary for the Dcm module to lock or unlock the record updates of the Dem module.

[SWS_Dcm_00287]

[ ]

Upon the completion of [SWS_Dcm_00286], the Dcm shall generate a response message including the respective PID, FreezeFrame Number and the associated data record for the requested FreezeFrame number.

[SWS_Dcm_01252]

[ ]

If Dem_DcmReadDataOfOBDFreezeFrame() returns E_NOT_OK and a single PID is requested, the Dcm shall not provide any answer.

[SWS_Dcm_01253]

[ ]

If Dem_DcmReadDataOfOBDFreezeFrame() returns E_NOT_OK and all PIDs from the requested multiple PID(s) are not supported, the Dcm shall not provide any answer.

[SWS_Dcm_01254]

[ ]

If Dem_DcmReadDataOfOBDFreezeFrame() returns E_NOT_OK and at least one PID from the requested multiple PID(s) is supported, the Dcm shall send a positive response including the data of the supported PID(s).

Service $03 $07 $0A - Obtaining DTCs

[SWS_Dcm_00245]

[ ]

The Dcm module shall implement OBD Service $03 (Request emission-related diagnostic trouble codes) in compliance to all provisions of the OBD standard.

[SWS_Dcm_00410]

[ ]

The Dcm module shall implement OBD Service $07 (Request Emission-Related Diagnostic Trouble Codes Detected during Current or Last Completed Driving Cycle) in compliance to all provisions of the OBD standard.

[SWS_Dcm_00411]

[ ]

The Dcm module shall implement OBD Service $0A (Request Emission-Related Diagnostic Trouble Codes with Permanent Status) in compliance to all provisions of the OBD standard.

An external test tool can request an emission-related ECU to report all stored, pending or permanent emission-related DTCs by sending the request $03, $07, $0A respectively.

[SWS_Dcm_00289]

[ ]

When receiving a request for OBD Service $03, the Dcm module shall obtain from the DEM all DTCs in primary memory and with a "confirmed" status using the functions Dem_SetDTCFilter() and Dem_GetNextFilteredDTC().

Note:

[SWS_Dcm_00412]

[ ]

When receiving a request for OBD Service $07, the Dcm module shall obtain from the DEM module all DTCs in primary memory with a "pending" status using the functions Dem_SetDTCFilter() and Dem_GetNextFilteredDTC().

Note:

[SWS_Dcm_00330]

[ ]

When receiving a request for OBD Service $0A, the Dcm module shall obtain from the DEM all DTCs stored in permanent memory using the functions Dem_SetDTCFilter() and Dem_GetNextFilteredDTC().

Note:

The following table illustrates the parameters the Dcm module must use when calling Dem_SetDTCFilter() in response to a request for OBD Service $03, $07 or $0A.

Table 7.30: Dem_SetDTCFilter Parameters

[SWS_Dcm_01227]

[ ]

Dem_GetNextFilteredDTC returns DEM_NO_SUCH_ELEMENT and at least one matching element could be retrieved before, the Dcm shall send a positive response including these data elements and the number of DTCs.

[SWS_Dcm_01228]

[ ]

If Dem_GetNextFilteredDTC returns DEM_NO_SUCH_ELEMENT and no matching element could be retrieved before, the Dcm shall send a positive response with the number of DTCs set to 0x00.

Service $04 - Clear/reset emission-related diagnostic information

[SWS_Dcm_00246]

[ ]

The Dcm module shall implement OBD Service $04 (Clear/reset emission-related diagnostic information) in compliance to all provisions of the OBD standard.

An external test tool can request an emission-related ECU to clear the error memory by sending the request $04.

[SWS_Dcm_00004]

[RS_Diag_04058]

When receiving a request for OBD Service $04, the Dcm module shall call the interface Dem_SelectDTC with the following parameter values:

ClientId: Client Id for this Dcm instance (see DcmDemClientRef)

DTC = DEM_DTC_GROUP_ALL_DTCS

DTCFormat = DEM_DTC_FORMAT_OBD

DTCOrigin = DEM_DTC_ORIGIN_OBD_RELEVANT_MEMORY

[SWS_Dcm_00413]

[ ]

In case Dem_ClearDTC() returns E_OK, the Dcm module shall send a positive response.

[SWS_Dcm_00703]

[RS_Diag_04249]

In case Dem_ClearDTC() returns DEM_PENDING, the Dcm shall invoke Dem_ClearDTC() on next Dcm_MainFunction call again. It is up to the Dcm to send NRC 78 (ResponsePending) to respect the response behaviour

[SWS_Dcm_00704]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_FAILED, the Dcm shall send a negative response 0x22 (conditionsNotCorrect).

[SWS_Dcm_00967]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_BUSY, the Dcm shall send a negative response 0x22 (ConditionsNotCorrect).

[SWS_Dcm_01067]

[ ]

In case Dem_ClearDTC() returns DEM_CLEAR_MEMORY_ERROR, the Dcm module shall send a negative response 0x22 (ConditionNotCorrect).

Service $06 - Request On-Board Monitoring Test-results for Specific Monitored Systems

General requirements

[SWS_Dcm_00414]

[ ]

The Dcm module shall implement OBD Service $06 (Request OnBoard Monitoring Test-results for Specific Monitored Systems) in compliance to all provisions of the OBD standard.

Using Service $06, an external test tool can request an emission-related ECU to return the DTR's associated with the OBDMID or to return the supported OBDMIDs. OBD reserves certain OBDMIDs for the special purpose of obtaining the list of supported OBDMIDs in a certain range. These OBDMIDs are called "availability OBDMIDs" and are $00, $20, $40, $60, $80, $A0, $C0 an $E0.

A tester request for supported OBDMIDs may contain up to six (6) "availability OBDMIDs".

[SWS_Dcm_00945]

[ ]

On reception of an OBD Service $06 request with "availability OBDMIDs" together with other OBDMIDs as parameter, the Dcm module shall ignore the request.

[SWS_Dcm_00956]

[ ]

On reception of an OBD Service $06 request with multiple nonavailability OBDMIDs, the Dcm module shall ignore the request.

Test results obtained via Dem interaction

The maintenance of the DTRs lies within the responsibility of the DEM. SW-Cs reporting DTRs use dedicated interfaces offered by the DEM. Upon requests from the tester the Dcm retrieves the information from the DEM using dedicated DEM interfaces. There is no direct interaction between the Dcm and SW-Cs.

[SWS_Dcm_00957]

[ ]

On reception of an OBD Service $06 request with only "availability OBDMID(s)" as parameter(s), the Dcm module shall obtain the supported OBDMIDs by calling the Dem interface Dem_DcmGetAvailableOBDMIDs()for each "availability OBDMID ($00, $20, ...)" contained within the request and concatenate the results within the response message according to ISO-15031-5 [2].

[SWS_Dcm_00958]

[ ]

On reception of an OBD Service $06 request with an OBDMID that is not an "availability OBDMID", the Dcm module shall call the DEM interface Dem_DcmGetNumTIDsOfOBDMID() to obtain the TIDs available for the requested OBDMID and then recurrently call the interface Dem_DcmGetDTRData() for the number of reported TIDs to obtain the associated DTR data.

Service $08 - Request Control of On-Board System, Test or Component

[SWS_Dcm_00417]

[ ]

The Dcm module shall implement OBD Service $08 (Request Control of On-Board System, Test or Component) in compliance to all provisions of the OBD standard.

Using Service $08, an external test tool can control an on-board system, test or component using a TID. OBD reserves certain TIDs for the special purpose of obtaining the list of supported TIDs in a certain range. These TIDs are called "availability TIDs" and are $00, $20, $40, $60, $80, $A0, $C0 an $E0.

The Dcm module's configuration defines the TIDs that are available on the ECU for the purpose of OBD Service $08. The configuration defines for each such TID (see configuration parameter DcmDspRequestControlTestId):

the name of the port the Dcm uses to access the RequestControlServices interface (see configuration parameter DcmDspRequestControl)

the number of bytes this function takes as input (see configuration parameter DcmDspRequestControlInBufferSize)

the number of bytes this function writes as output (see configuration parameter DcmDspRequestControlOutBufferSize)

To provide OBD Service $08, the Dcm relies on external functions configured per TID.

[SWS_Dcm_00418]

[ ]

On reception of an OBD Service $08 request with one or more "availability TIDs" as parameter, the Dcm module shall respond with the corresponding supported (=configured) TIDs.

[SWS_Dcm_00947]

[ ]

On reception of an OBD Service $08 request "availability TIDs" together with other TIDs as parameter, the Dcm module shall ignore the request.

[SWS_Dcm_00419]

[ ]

On reception of an OBD Service $08 request with a TID that is not an "availability TID", the Dcm module shall invoke the configured Xxx_RequestControl() function with the following parameters values: InBuffer: data contained in the OBD request (the size of which must correspond to the size configured in the Dcm module's configuration) OutBuffer: space in which the RequestControl function can store its result (the size of the buffer is taken from the Dcm module's configuration)

[SWS_Dcm_00420]

[ ]

After the execution of [SWS_Dcm_00419], the Dcm module shall respond to the service request using the data stored by the RequestControl function in the OutBuffer.

[SWS_Dcm_00948]

[ ]

As specified in [3, SAE J1979], unused data bytes shall be filled with $00.

[SWS_Dcm_01192]

[ ]

If Xxx_RequestControl() doesn't return E_OK, the Dcm shall return NRC 0x22.

Service $09 - Request Vehicle Information

[SWS_Dcm_00421]

[ ]

The Dcm module shall implement OBD Service $09 (Request Vehicle Information) in compliance to all provisions of the OBD standard.

Using Service $09, an external test tool can request vehicle information or can obtain lists of supported vehicle information. OBD reserves certain InfoTypes for the special purpose of obtaining the list of supported InfoTypes in a certain range. These Infotypes are called "availability InfoTypes" and are $00, $20, $40, $60, $80, $A0, $C0 an $E0.

The Dcm module's configuration defines the InfoTypes and associated data that are available on one or several SW-C. The configuration defines for each such InfoType:

The value of InfoType (see configuration parameter DcmDspVehInfoInfoType)

For every data of the InfoType:

The position of this data in the InfoType (see configuration parameter DcmDspVehInfoDataOrder)

the size of the value of the InfoType data (see configuration parameter DcmDspVehInfoDataSize)

the function that the Dcm module must call to obtain the value for this InfoType data OR the port-name through which the Dcm module can obtain the value for this InfoType data (see configuration parameter DcmDspVehInfoDataReadFnc and DcmDspVehInfoDataUsePort).

To provide OBD Service $09, the Dcm relies on external functions that allow it to obtain the value of an InfoType data. There is one such function per InfoType data that is needed by the DCM.

When invoking a Xxx_GetInfotypeValueData() function, the Dcm module provides a buffer of the correct size in which the value of the InfoType data can be stored. The entity providing the actual implementation of the Xxx_GetInfotypeValueData() function for a specific InfoType data might be a SW-C or another basic software module. The origin of the function is part of the Dcm module's configuration.

Certain InfoTypes needed by the Dcm to provide Service $09 are provided by the DEM. This is handled in the Dcm configuration.

[SWS_Dcm_00422]

[ ]

On reception of an OBD Service $09 request with one or more "availability InfoTypes" as parameter, the Dcm module shall respond with the corresponding supported (=configured) InfoTypes.

[SWS_Dcm_00949]

[ ]

On reception of an OBD Service $09 request "availability InfoTypes" together with other InfoTypes as parameter, the Dcm module shall ignore the request.

[SWS_Dcm_00423]

[ ]

On reception of an OBD Service $09 request for an InfoType that is not an "availability InfoType", the Dcm module shall obtain the value of this InfoType by invoking all the configured Xxx_GetInfotypeValueData() function for every data of this InfoType and shall return the value as response to Service $09

[SWS_Dcm_00684]

[ ]

In case DcmDspVehInfoNODIProvResp is set to FALSE, in addition to collect the available InfoType value contributions from the individual SW-C, the Dcm shall compute the data byte NofDataItems in the diagnostic response, which defines the number of DataItems included in one InfoType.

Note:

The Calculation of the Calibration Identification (CAL-ID) and Calibration Verification Number (CVN) is not a BSW Task and will not handled within the DCM.

[SWS_Dcm_01167]

[ ]

In case DcmDspVehInfoNODIProvResp is set to TRUE, the Dcm shall take over the value returned by the provider and report it as NofDataItems in the diagnostic response.

[SWS_Dcm_CONSTR_06045]

[ ]

In case the responsibility is on provider side (DcmDspVehInfoNODIProvResp is set to TRUE), only one DcmDspVehInfoData container shall be allowed.

[SWS_Dcm_CONSTR_06046]

[ ]

In case DcmDspVehInfoDataUsePort is set to FALSE and DcmDspVehInfoDataReadFnc is set to either Dem_DcmGetInfoTypeValue08 or Dem_DcmGetInfoTypeValue0B then DcmDspVehInfoNODIProvResp shall be set to TRUE.

Note :

The integrator has to make sure that the buffer determined by the DcmDspVehInfoDataSize is sufficiently sized to receive the data returned by the provider of the data.

[SWS_Dcm_01191]

[ ]

If Xxx_GetInfoTypeValueData() doesn't return E_OK or E_PENDING, the Dcm shall return NRC 0x22.

Interaction usecases

The Dcm shall be able to manage a jump to the bootloader / jump due to ECUReset request. Due to the diversity of possibility to realize this jump, this will be done using callout call.

Jump to Bootloader

4 different use cases have been identified for the jump to the bootloader, if all preconditions are fulfilled and assuming the 'suppressPosRspMsgIndicationBit ' flag is set to 'false':

The application immediately sends a final positive response and then jumps to the bootloader

The application first sends a NRC 0x78 response, then the final positive response and afterwards jumps to the bootloader

The application immediately jumps to the bootloader and the bootloader sends the final positive response

The application first sends a NRC 0x78 response, then jumps to the bootloader and the bootloader sends the final positive response

Note:

In case the 'suppressPosRspMsgIndicationBit' flag is set to 'true', use case '1' and use case '3' will not issue a positive response.

[SWS_Dcm_00532]

[RS_Diag_04098]

On reception of service DiagnosticSessionControl if the provided session is used to jump to OEM bootloader (parameter DcmDspSessionForBoot set to DCM_OEM_BOOT or DCM_OEM_BOOT_RESPAPP) the Dcm shall prepare the jump to the OEM bootloader (see [SWS_Dcm_00535]) by triggering the mode switch of ModeDeclarationGroupPrototype DcmEcuReset to JUMPTOBOOTLOADER.

Note:

By this mode switch the Dcm informs the BswM to prepare the jump to the bootloader.

[SWS_Dcm_00592]

[RS_Diag_04098]

On reception of service DiagnosticSessionControl if the provided session is used to jump to System Supplier bootloader (parameter DcmDspSessionForBoot set to DCM_SYS_BOOT or DCM_SYS_BOOT_RESPAPP) the Dcm shall prepare the jump to the System Supplier bootloader (see [SWS_Dcm_00535]) by triggering the mode switch of ModeDeclarationGroupPrototype DcmEcuReset to JUMPTOSYSSUPPLIERBOOTLOADER

Note:

By this mode switch the Dcm informs the BswM to prepare the jump to the bootloader.

[SWS_Dcm_01164]

[ ]

In case the service DiagnosticSessionControl implies an ECU reset, the Dcm shall ignore all further requests while that reset is being processed.

[SWS_Dcm_00654]

[RS_Diag_04098]

[RS_Diag_04249]

In case the ModeDeclarationGroupPrototype DcmEcuReset is switched to mode JUMPTOBOOTLOADER or JUMPTOSYSSUPPLIERBOOTLOADER and the configuration parameter DcmSendRespPendOnRestart is set to TRUE, the Dcm shall trigger transmission of NRC 0x78 - RCR-RP.

Note:

This final transmission of NRC 0x78 before switching to Bootloader shall reload the P2* timeout in the client.

[SWS_Dcm_01175]

[ ]

In case the ModeDeclarationGroupPrototype DcmEcuReset can not be switched JUMPTOBOOTLOADER or JUMPTOSYSSUPPLIERBOOTLOADER, the Dcm shall answer negatively to the request with NRC 0x22 (Conditions not correct).

[SWS_Dcm_00535]

[RS_Diag_04098]

If the jump to bootloader is requested (see [SWS_Dcm_00532], [SWS_Dcm_00592], the configuration parameter DcmSendRespPendOnRestart is set to TRUE (see [SWS_Dcm_00654]) and the configuration parameter DcmDspSessionForBoot is set to DCM_OEM_BOOT or DCM_SYS_BOOT, the Dcm shall call Dcm_SetProgConditions after a successful transmission of NRC 0x78 (Response pending).

This will allow to store all relevant information prior to jumping to the bootloader.

Note:

It is up to the software integrator to decide where to store that data. Usually it will be stored in non-volatile memory like e.g. data flash. It is also acceptable to "store" this data in a RAM section which is not initialized out of reset.

[SWS_Dcm_01163]

[RS_Diag_04098]

In the context of a request to jump to the bootloader (see [SWS_Dcm_00532] and [SWS_Dcm_00592]), after Dcm_SetProgConditions returns E_OK according to [SWS_Dcm_00535], the Dcm shall trigger the mode switch of the ModeDeclarationGroupPrototype DcmEcuReset to EXECUTE.

[SWS_Dcm_01177]

[RS_Diag_04098]

If the jump to bootloader is requested (see [SWS_Dcm_00532], [SWS_Dcm_00592], the configuration parameter DcmSendRespPendOnRestart is set to TRUE (see [SWS_Dcm_00654]), and the configuration parameter DcmDspSessionForBoot is set to DCM_OEM_BOOT_RESPAPP or DCM_SYS_BOOT_RESPAPP, the Dcm shall initiate the final response after a successful transmission of NRC 0x78 (Response pending).

[SWS_Dcm_00995]

[ ]

If the NRC 0x78 (Response Pending) response in [SWS_Dcm_00535] is not sent successfully the Dcm shall cancel the current request.

[SWS_Dcm_00997]

[ ]

If the NRC 0x78 (Response Pending) response in [SWS_Dcm_00535] is not sent successfully no jump to the bootloader shall be performed

Note:

If the NRC 0x78 (Response Pending) response has not been sent correctly the Dcm will stay in the application and wait for the next request from the Client.

[SWS_Dcm_01178]

[ ]

In case the ModeDeclarationGroupPrototype DcmEcuReset is switched to mode JUMPTOBOOTLOADER or JUMPTOSYSSUPPLIERBOOTLOADER, the configuration parameter DcmSendRespPendOnRestart is set to FALSE and the configuration parameter DcmDspSessionForBoot is set to DCM_OEM_BOOT_RESPAPP or DCM_SYS_BOOT_RESPAPP , the Dcm shall initiate the final response

[SWS_Dcm_01179]

[ ]

In case the final response has been successfully sent according to [SWS_Dcm_01177] or [SWS_Dcm_01178], the Dcm shall call Dcm_SetProgConditions

[SWS_Dcm_01180]

[ ]

If Dcm_SetProgConditions returns E_OK according to [SWS_Dcm_01179], the Dcm shall trigger the mode switch of the ModeDeclarationGroupPrototype DcmEcuReset to EXECUTE.

[SWS_Dcm_01181]

[ ]

If Dcm_SetProgConditions returns E_NOT_OK according to [SWS_Dcm_01179], the Dcm shall not request any reset, shall not perform the jump to bootloader, and shall not switch the ModeDeclarationGroupPrototype DcmEcuReset to EXECUTE.

[SWS_Dcm_00720]

[ ]

In case the ModeDeclarationGroupPrototype DcmEcuReset is switched to mode JUMPTOBOOTLOADER or JUMPTOSYSSUPPLIERBOOTLOADER, the configuration parameter DcmSendRespPendOnRestart is set to FALSE and the configuration parameter DcmDspSessionForBoot it set to DCM_OEM_BOOT or DCM_SYS_BOOT, the Dcm shall call Dcm_SetProgConditions immediately. (see [SWS_Dcm_00532] and [SWS_Dcm_00592])

[SWS_Dcm_00719]

[ ]

If Dcm_SetProgConditions returns E_OK according to [SWS_Dcm_00720], the Dcm shall shall trigger the mode switch of the ModeDeclarationGroupPrototype DcmEcuReset to EXECUTE without sending a NRC 0x78 (Response pending).

In case of [SWS_Dcm_00719], the exact response handling depends on the state of the 'suppressPosRspMsgIndicationBit' (TRUE or FALSE) in the request message.

[SWS_Dcm_00715]

[ ]

If the jump to bootloader is requested (see [SWS_Dcm_00532] and [SWS_Dcm_00592]) and if the call to Dcm_SetProgConditions returns E_NOT_OK (see [SWS_Dcm_00535] and [SWS_Dcm_00720]), no further action shall be taken by the Dcm and negative response NRC 0x22 (Conditions not correct) shall be returned.

Jump due to ECUReset

On reception of an ECUReset Service 0x11 request, if the configuration parameter DcmResponseToEcuReset is set to AFTER_RESET, the Dcm will set the ResponseRequired flag by calling Dcm_SetProgConditions.

Answer to ECUReset request

[SWS_Dcm_01423]

[RS_Diag_04098]

On reception of an ECUReset Service 0x11 request, if DcmResponseToEcuReset is set to AFTER_RESET, the Dcm shall answer to EcuReset service after the reset.

Answer to ECUReset request

[SWS_Dcm_01424]

[RS_Diag_04098]

On reception of an ECUReset Service 0x11 request, if DcmResponseToEcuReset is set to BEFORE_RESET, the Dcm shall answer to EcuReset service before the reset.

Answer to ECUReset request

[SWS_Dcm_01425]

[RS_Diag_04098]

[RS_Diag_04249]

If the Dcm intiates a reset and DcmSendRespPendOnRestart is set to TRUE, the Dcm shall trigger transmission of NRC 0x78 (Response pending) before the reset.

Jump from Bootloader / ECUReset

[SWS_Dcm_00536]

[RS_Diag_04098]

At Dcm initialization, the Dcm shall call Dcm_GetProgConditions to know if the initialization is the consequence of a jump from the bootloader / ECUReset.

Note:

It is the responsibility of the software integrator to ensure that the data contained in Dcm_ProgConditionsType is valid when Dcm_Init is called. E.g. if this data is stored in non-volatile memory, it may take some time to make it available after an ECU reset. This has to be taken into account when designing the ECU's startup process.

[SWS_Dcm_00537]

[ ]

If the initialization of the Dcm is the consequence of a jump from the bootloader / ECUReset (see [SWS_Dcm_00536], the Dcm shall call ComM_DCM_ActiveDiagnostic(NetworkId) to request the ComManager for the full communication mode.

[SWS_Dcm_00767]

[RS_Diag_04098]

When the ComM reports full communication to the Dcm, the Dcm shall send the Response to the Service Id passed in the Dcm_ProgConditionsType.

[SWS_Dcm_00768]

[ ]

If the initialization of the Dcm is the consequence of a jump from the bootloader (see [SWS_Dcm_00536] and the application is updated by an FLASH download (Dcm_ProgConditionsType.ApplUpdated == True), the Dcm shall call BswM_Dcm_ApplicationUpdated() to notify the BswM that the application was updated.

Flags management

Jump to Bootloader

[SWS_Dcm_01182]

[ ]

On reception of a UDS Service 0x10 request (Diagnostic Session Control) with subfunction 0x02 (Start Programming Session), the Dcm shall set the ReprogramingRequest flag and, if indicated for this service, the ResponseRequired flag by calling Dcm_SetProgConditions.

[SWS_Dcm_01183]

[ ]

Depending on configuration parameter DcmDspSessionForBoot, either the application shall send the positive response (if suppressPosRspMsgIndicationBit = FALSE) or after an ECU reset, when the bootloader is started, it shall send a response and clear the ResponseRequired flag. In either case, the bootloader shall clear the ReprogramingRequest flag.

[SWS_Dcm_01185]

[ ]

In case that, during jump to Bootloader, the Dcm_SetProgConditions API returns E_NOT_OK, a DET error shall be reported DCM_E_SET_- PROG_CONDITIONS_FAIL and normal functionality shall resume.

Jump from Bootloader

After successful reprograming of the application software, the bootloader will update the ApplUpdated flag and the ResponseRequired flags.

After an ECU reset, when the newly programmed application is started for the first time, the Dcm will read the ApplUpdated and ResponseRequired flag by calling Dcm_GetProgConditions. During this function call the ApplUpdated and ResponseRequired flags are cleared by the integration code.

Error notification

The Default Error Tracer module is just help for BSW development and integration. It must not be contained inside the production code. The API is defined, but the functionality can be chosen and implemented according to the development needs (e.g. errors count, send error information via a serial interface to an external logger, and so on).

Synchronous and Asynchronous implementation

The Dcm can access data using an R-Port requiring either a synchronous or an asynchronous ClientServertInterface DataServices_{Data}. In the Dcm SWS, the parameter DcmDspDataUsePort is set to USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR.

In case of USE_DATA_SYNCH_CLIENT_SERVER, the interface shall be compatible with the Dem interface "DataServices_<Data>" (no OpStatus parameter). The parameter OpStatus and return parameter DCM_E_PENDING shall only be available in case of USE_DATA_ASYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER_ERROR.

Note:

a Dcm implementation using AsynchronousServerCallPoint or SynchronousServerCallPoint when calling service processors is completely an implementation decision. This only indicates that the operation uses the status of the operation to allow an asynchronous processing by the SW-C (initiating a request, checking if a request is still pending, or canceling a pending request, see [SWS_Dcm_00686]).

There is no correlation to the operation signature (i.e. existence of OpStatus parameter and DCM_E_PENDING return code) that demands AsynchronousServerCallPoint or SynchronousServerCallPoint usage.

[SWS_Dcm_01187]

[ ]

If an asynchronous interface is used, the Dcm shall consider the Output data (OUT) only valid after the last call to the interface that returns E_OK.

[SWS_Dcm_01188]

[ ]

If an asynchronous interface is used, the Dcm shall consider the OUT-parameter ErrorCode only valid after the last call to the interface that returns E_NOT_OK

Note :

The "last call" to the interface is the call that returns with a value that indicates that processing has finished, i.e. E_OK or E_NOT_OK.

Note :

INOUT parameter are a combination of the requirements above, i.e. on each call of the interface the parameters shall have a valid in-value, and the Dcm considers the out-value valid only after the last call of the interface.

[SWS_Dcm_01189]

[ ]

If an asynchronous interface is used, the Dcm shall provide the values originating from the request for the Input data (IN) on every call to the interface.

Note:

Requirements [SWS_Dcm_01187], [SWS_Dcm_01188] and [SWS_Dcm_01189] do not apply for functions where a deviant behaviour is explicitly specified.

DID configuration

The configuration of the Dcm contains a list of supported DIDs which can be configured in two ways:

The individual DID configuration,which required one connection (either via a port or a c-function) per configured data element of the respective DID to access to the data (reading, writing and controlling). The interface DataServices should be used for each DID in this case.

The DID range configuration, used to handle a set of DIDs sharing the same behavior uniformly in one SW-C with only one port-connection. The interface DataServices_DIDRange_{Range} should be used in this case. Using this configuration allows an interface optimization.The following parameters shall be configured in order to use the DIDRange optimization: DcmDspDidRangeIdentifierLowerLimit and DcmDspDidRangeIdentifierUpperLimit which delimited the range of the DIDs. DcmDspDidRangeMaxDataLength and DcmDspDidRangeHasGaps.

[SWS_Dcm_01174]

[ ]

If DcmVinRef is configured then the VIN shall be fetched once by the Dcm during startup by calling Dcm_GetVin.

Individual DID

The individual DID can be configured in DcmDspDid. A unique DID identifier is configured on 2 bytes in DcmDspDidIdentifier. In case the DID refers to other DIDs, the link between them can be configured in DcmDspDidRef (Overview of DcmDspDid container is described in chapter 10.2.5.8.1) . Each DID allows to access to signal data values (by reading and/or writing). The signal reference (to DcmDspData) and the position of the data in the diagnostic answer (for reading) or request (for writing) can be configured in DcmDspDidSignal.

The configuration of the data belonging to the DID can be provided in the container DcmDspData (ECUC_Dcm_00869). This container collects the following information:

The Data endianness of the data belonging to the DID (ECUC_Dcm_00986: DcmDspDataEndianness)

The length and the type of the data (ECUC_Dcm_00605: DcmDspDataByteSize, ECUC_Dcm_00985 : DcmDspDataType)

The interface to be used to access to the data (ECUC_Dcm_00713: DcmDspDataUsePort)

The NRAM blockId to access the data (ECUC_Dcm_00809 : DcmDspDataBlockIdRef)

The interfaces to the application in order to :

Check if the DID can be accessed in the current conditions. This can be achieved by checking for each DataElement if the conditions to read the data are satisfied (ECUC_Dcm_00677: DcmDspDataConditionCheckReadFnc and ECUC_Dcm_00955: DcmDspDataConditionCheckReadFncUsed)

Request to freeze the current state of an IOControl (ECUC_Dcm_00674: DcmDspDataFreezeCurrentStateFnc)

Get the scaling information of the DID. This can be achieved by getting the scaling information for each DataElement (ECUC_Dcm_00676: DcmDspDataGetScalingInfoFnc)

Request the data length of a DataElement (ECUC_Dcm_00671: DcmDspDataReadDataLengthFnc)

Read a certain ECU signal (ECUC_Dcm_00824: DcmDspDataReadEcuSignal).

Access in reading or writing to the data (ECUC_Dcm_00669 : DcmDspDataReadFnc, ECUC_Dcm_00670: DcmDspDataWriteFnc)

Request to reset an IOControl to default value (ECUC_Dcm_00673 : DcmDspDataResetToDefaultFnc)

Request to return control to ECU of an IOControl (ECUC_Dcm_00672 : DcmDspDataReturnControlToEcuFnc)

Request to adjust the IO signal (ECUC_Dcm_00675 : DcmDspDataShortTermAdjustmentFnc)

It is also possible to configure an alternative diagnosis representation via ECUC_Dcm_00993: DcmDspDiagnosisScaling.

The following example shows how to configure the containers DcmDspDid and DcmDspData for an individual DID 0xF080. This configuration allows access to a byte of data via synchronous C APIs WriteDID_F080 (for writing) and ReadDID_F080 (for reading).

DcmDspDidIdentifier=0xF080

DcmDspDidByteOffset=0

DcmDspDidDataRef=DcmDspData_F080

DcmDspDataByteSize=8

DcmDspDataType=UINT8_N

DcmDspDataUsePort=USE_DATA_SYNCH_FNC

DcmDspDataWriteFnc=WriteDID_F080

DcmDspDataReadFnc=ReadDID_F080

Dependency for DcmDspDataBlockIdRef

[SWS_Dcm_CONSTR_06067]

[ ]

DcmDspDataBlockIdRef shall be only present if DcmDspDataUsePort is set to USE_BLOCK_ID.

DID ranges

DID ranges are in general the same as the 'normal' DID read and write function, except that the DID is also passed as a parameter. This allows to treat the DID range in a switch/case in the read or the write function.

The ranges can be applied for reading (ReadDataByIdentifier 0x22) and writing (WriteDataByIdentifier 0x2E) DIDs. The ranges can be configured in ECUC_Dcm_00937 : DcmDspDidRange. Each configured range is by default accessible by service 0x22 and 0x2E. In case the range should be limited to reading or writing, the referenced DcmDspDidInfo container should be defined accordingly.

It is also possible to define gaps within the range (DcmDspDidRangeHasGaps). By activating this feature, the Dcm invokes each time a DID is requested within the configured range, the operation IsDidAvailable has to check the current availability. And as the DIDs of the specified range can have different length, the length of the longest DID has to be configured (DcmDspDidRangeMaxDataLength) in order to reserve enough buffer passed to the respective function.

In general, the range functionality can also be used for a single DID if you specifically want to pass the DID as a parameter. Then lower DID and upper DID should be the same.

ReadDidRangeDataLength operation allows to request the application to return the data length of a DID Range.

Definition of allowed DID access

[SWS_Dcm_CONSTR_06020]

[ ]

Any defined range shall only reference via DcmDspDidRangeInfoRef. The sub-containers DcmDspDidControl and DcmDspDidDefineinDcmDspDidInfo shall not be used] .

DID ranges cannot be mapped on DDDIDs, because service 0x2C DDDID does not support the range feature. Practically DcmDspDidRangeIdentifierLowerLimit and DcmDspDidRangeIdentifierUpperLimit should not include DIDs of the range 0xF200 till 0xF3FF

[SWS_Dcm_CONSTR_06021]

[ ]

Any defined range shall only reference DcmDspDidInfo via DcmDspDidRangeInfoRef, having set DcmDspDidDynamicallyDefined == False.

Startup behavior

[SWS_Dcm_00334]

[ ]

Dcm_Init shall initialize all Dcm global variables with the values of the configuration

AUTOSAR_SWS_DiagnosticCommunicationManager

Specification of Diagnostic Communication Manager

Introduction and functional overview

Acronyms and Abbreviations

Typographical Conventions

Related documentation

Input documents & related standards and norms

Related specification

Constraints and assumptions

Limitations

Applicability to car domains

Applicability to emission-related environments (OBD)

Dependencies to other modules

Requirements Tracing

Functional specification

Security Events

Security events for Dcm

Error Classification

Development Errors

Runtime Errors

General design elements

Submodules within the Dcm module

Negative Response Code (NRC)

Non-volatile information

Types

Atomic types overview

Data array types overview

Nested Data types overview

Data types constraints

Existence of size parameter

Restrictions on size parameter for 16 Bit arrays

Restrictions on size parameter for 32 Bit arrays

Define the usage of DcmDspRoutineParameterSize parameter

Only last parameters in RID may have a variable length

Existence of size parameter

Restrictions on size parameter for 16 Bit arrays

Restrictions on size parameter for 32 Bit arrays

Restrictions on datatype usage

Usage of variable data length in case of S/R communication, NvRam access or ECU signal access

Dcm_OpStatusType

Dcm_Cemr_{DID}Type

Diagnostic Session Layer (DSL)

Introduction

Use cases

Interaction with other modules

Functional description

Overview

Forward requests from the PduR module to the DSD submodule

Dcm_StartOfReception

Dcm_CopyRxData

Dcm_TpRxIndication

Concurrent TesterPresent ("keep alive logic")

Dcm_CopyTxData

Dcm_TpTxConfirmation

Forward responses from the DSD submodule to the PduR module

Generic Connection Handling

Target address for generic connection transmission

Guarantee timing to tester by sending busy responses

Support of periodic transmission

Support of segmented response (paged-buffer)

Dependency for DcmDslProtocolMaximumResponseSize

Support of ResponsePending response triggered by the Application

Manage security level

Dependency on DcmDspSecurityAttemptCounterEnabled

Initialization sequence

Dependency for DcmDspSecurityGetAttemptCounterFnc

Dependency for DcmDspSecurityMaxAttemptCounterReadoutTime

AttemptCounter update

Dependency for DcmDspSecuritySetAttemptCounterFnc

Manage session state

Manage authentication state

Authentication state per connection

Mode declaration group per authentication state

Authentication states

Initialization of authentication state

Initialization of persisted authentication states

Fallback to deauthenticated session on idle connection

Fallback to deauthenticated session on S3server timeout

Clearing persisted authentication state

Reaction of fallback into deauthenticated state