Diagnostic Communication Manager (DCM)

La fonction synchrone et non réentrante Dcm_Init sert à l'initialisation fondamentale du module DCM [SWS_Dcm_00037]. Elle reçoit via le paramètre ConfigPtr un pointeur vers le jeu de configuration pour les variantes post-build et ne possède pas de valeur de retour [SWS_Dcm_00037]. Pendant son exécution, le module initialise toutes les variables globales du DCM avec les valeurs issues de la configuration [SWS_Dcm_00334].

Dans le cadre de la séquence d'initialisation, différents domaines fonctionnels et états sont configurés :

• Gestion des DDDID : si le paramètre de configuration DcmDDDIDStorage est défini sur FALSE, le DCM initialise au démarrage tous les identifiants de données définis dynamiquement (DDDID) comme non présents [SWS_Dcm_00866]. Si le paramètre est défini sur TRUE, les définitions de DDDID sont restaurées à partir de la NvM [SWS_Dcm_00867].
• Response on Event (ROE) : le DCM fait passer l'état de chaque événement à l'état « ROE cleared » pendant Dcm_Init [SWS_Dcm_00872].
• État d'authentification : si DcmDspAuthenticationPersistStateModeRuleRef n'est pas configuré ou si la règle de mode référencée est évaluée à false, le module place tous les états d'authentification à l'état « deauthenticated » [SWS_Dcm_01480].
• État de communication : une fois Dcm_Init terminé, le DCM positionne le paramètre ActiveDiagnostic sur 'DCM_COMM_ACTIVE' [SWS_Dcm_01069].

Concernant l'environnement d'exécution, il est établi que Dcm_Init n'est pas réentrante [SWS_Dcm_00037]. Des codes d'erreur spécifiques ainsi que des messages d'erreur standardisés à destination de DET ou DEM ne sont pas indiqués dans la spécification d'interface pour ce service d'initialisation [SWS_Dcm_00037].

Utilisation

L'interface synchrone Dcm_DemTriggerOnDTCStatus (ID de service 0x2B) est disponible via l'en-tête Dcm_Dem.h et sert à signaler les modifications de l'octet d'état UDS au DCM [SWS_Dcm_00614]. Cela permet au DCM de déclencher des événements Response-on-Event (ROE) pour le sous-service de diagnostic OnDTCStatusChanged [SWS_Dcm_00614]. Lors de l'appel, la fonction reçoit trois paramètres d'entrée : le code d'erreur concerné DTC (uint32), l'état précédent DTCStatusOld (Dem_UdsStatusByteType) ainsi que l'état mis à jour DTCStatusNew (Dem_UdsStatusByteType) [SWS_Dcm_00614]. Aucun paramètre d'entrée-sortie n'existe [SWS_Dcm_00614].

Valeurs de retour et gestion des erreurs

Comme valeur de retour, la fonction fournit le type Std_ReturnType, E_OK étant renvoyé sans exception selon la spécification [SWS_Dcm_00614]. Aucun code d'erreur spécifique, valeur de repli ou notification distincte à DEM ou DET n'est désigné pour cet appel.

Concurrence et interaction

La fonction est classée comme réentrante et dispose d'une sémantique d'exécution synchrone [SWS_Dcm_00614]. En ce qui concerne l'interaction avec les requêtes de diagnostic, une condition limite stricte s'applique : si une requête d'effacement de la mémoire des événements (EventMemory) est actuellement en cours de traitement dans le DCM, le DCM doit ignorer les appels entrants du callback Dcm_DemTriggerOnDTCStatus [SWS_Dcm_01410].

La fonction Dcm_BndMWriteBlockFinish sert d'interface de notification du BndM vers le DCM afin d'indiquer l'achèvement d'une opération d'écriture de bloc [SWS_Dcm_91088]. La fonction est déclarée dans le fichier d'en-tête Dcm.h, possède l'ID de service 0x7a, ne renvoie aucune valeur de retour (void) et est exécutée de manière synchrone [SWS_Dcm_91088].

L'interface attend deux paramètres d'entrée [SWS_Dcm_91088] :

• BlockId (type : BndM_BlockIdType) : identifie le bloc dont le processus d'écriture est achevé.
• result (type : BndM_ResultType) : transmet le résultat de l'opération d'écriture au DCM.

L'interaction fonctionnelle et le comportement en cas d'erreur sont couplés aux opérations d'écriture atomiques BndM préalablement déclenchées par le DCM :

• Si Dcm_BndMWriteBlockFinish est appelée avec le statut result = E_OK, le DCM envoie une réponse de diagnostic positive à la requête en attente [SWS_Dcm_01584].
• Si la fonction est appelée avec result = E_NOT_OK, le DCM réagit en cas d'erreur par une réponse de diagnostic négative 0x72 (generalProgrammingFailure) [SWS_Dcm_01585].

En matière de concurrence, Dcm_BndMWriteBlockFinish est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_91088]. Les appelants doivent par conséquent s'assurer que la fonction n'est pas appelée de manière parallèle ou avec interruption par plusieurs contextes.

Utilisation et contexte d'appel

La fonction Dcm_SetDeauthenticatedRole est exécutée de manière synchrone et réentrante ([SWS_Dcm_91069]). Elle permet à un composant logiciel d'assigner, pour une connexion identifiée par connectionId, un nouveau rôle deauthenticatedRole du type Dcm_AuthenticationRoleType pour l'état désauthentifié ([SWS_Dcm_91069], [SWS_Dcm_01486]). Comme valeur de retour, E_OK est renvoyé sans exception ([SWS_Dcm_91069]).

Conditions d'état et traitement des erreurs

Un appel n'est traité par le DCM que si la connexion se trouve à l'état désauthentifié (deauthenticated state) ([SWS_Dcm_01487]). Comme la signature ne prévoit pas de valeurs d'erreur alternatives et renvoie toujours E_OK ([SWS_Dcm_91069]), un appel en dehors de cet état devrait vraisemblablement être rejeté sans message d'erreur. Question Q-6f14770eae6ce896 (ouverte) Aucun événement DET ou DEM spécifique n'est défini dans la spécification.

Durée de validité et cycle de vie

Si le rôle pour l'état désauthentifié est appliqué avec succès ([SWS_Dcm_01486]), cette assignation reste temporairement en vigueur :

• Le rôle défini est rejeté dès que la connexion passe à l'état authentifié (authenticated state) ([SWS_Dcm_01488]).
• La validité prend fin au plus tard lors d'un reset du calculateur ([SWS_Dcm_91069]).

La fonction synchrone et réentrante Dcm_GetSecurityLevel interroge le niveau de sécurité actuellement actif du DCM et le met à disposition [SWS_Dcm_00338]. La fonction est déclarée via l'en-tête Dcm.h et transmet la valeur d'état déterminée à l'appelant via le paramètre de sortie SecLevel de type Dcm_SecLevelType*. Conformément à la spécification, E_OK est retourné sans exception comme valeur de retour [SWS_Dcm_00338].

La détermination du niveau de sécurité interne repose sur le paramètre SecurityAccessType transmis par le testeur dans le cadre du service SecurityAccess selon la formule de conversion fixe SecurityLevel = (SecurityAccessType + 1) / 2 [SWS_Dcm_00338].

En interaction avec le traitement des services de diagnostic de niveau supérieur, le sous-module DSP recourt notamment à cette valeur : si le module reçoit une requête configurée avec le type de sous-fonction « requestSeed » (valeur impaire) et si le niveau d'accès associé est déjà actif selon Dcm_GetSecurityLevel, le sous-module DSP définit le contenu de seed sur 0x00 [SWS_Dcm_00323].

Concernant la concurrence et la gestion des erreurs, la fonction est définie comme réentrante [SWS_Dcm_00338]. Comme aucun code d'erreur spécifique ou contrôle DET n'est spécifié et que E_OK est toujours renvoyé, aucun contrôle de pointeur nul ne devrait avoir lieu ; les appelants doivent donc vraisemblablement toujours transmettre un pointeur valide vers un espace mémoire pour SecLevel. Question Q-5402d82ac0151b22 (ouverte)

La fonction synchrone Dcm_ResetToDefaultSession permet à l'application de réinitialiser la session de diagnostic active vers la session par défaut (Default Session) [SWS_Dcm_00520]. Un cas d'usage typique est la clôture automatique d'une session de diagnostic étendue dès qu'un véhicule dépasse un seuil de vitesse prédéterminé [SWS_Dcm_00520].

Utilisation et traitement des erreurs

• Interface et paramètres : la fonction est disponible via Dcm.h avec le Service-ID 0x2a, possède la signature Std_ReturnType Dcm_ResetToDefaultSession (void) et ne requiert aucun paramètre d'entrée [SWS_Dcm_00520].
• Valeur de retour et erreurs : le type de retour fourni est Std_ReturnType, la valeur E_OK étant retournée sans exception [SWS_Dcm_00520]. Aucun code d'erreur spécifique, aucun contrôle DET au runtime ni aucun événement DEM n'est spécifié dans les exigences pour cet appel.

Concurrence et interaction

L'exécution est synchrone et est déclarée comme réentrante [SWS_Dcm_00520].

Outre le changement de session proprement dit, Dcm_ResetToDefaultSession déclenche obligatoirement un changement de mode pour le ModeDeclarationGroupPrototype DcmDiagnosticSessionControl [SWS_Dcm_01062]. Pour ce faire, la fonction appelle en interne SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnosticSessionControl_DCM_DEFAULT_SESSION) afin de notifier à l'environnement système le passage à la session par défaut [SWS_Dcm_01062].

La fonction synchrone Dcm_TriggerOnEvent (ID de service 0x2D), fournie via l'en-tête Dcm.h, sert à déclencher un événement associé à une requête ResponseOnEvent (ROE) [SWS_Dcm_00521].

Appel et fonctionnement

L'appelant transmet comme unique paramètre RoeEventId (paramètre d'entrée de type uint8), qui identifie l'événement à déclencher ; aucun paramètre d'entrée ou de sortie n'existe [SWS_Dcm_00521]. Dès que la fonction est appelée, le DCM vérifie l'état de l'événement : si le RoeEvent transmis est actif, le DCM déclenche l'événement correspondant [SWS_Dcm_00920]. Le DCM exécute le service associé à l'événement pour autant que le mode associé du RoeEventId soit positionné sur « ROE started » [SWS_Dcm_00521].

Valeurs de retour et validation

L'appel renvoie de manière synchrone un statut de type Std_ReturnType, qui renseigne sur la validité du paramètre [SWS_Dcm_00521] :

• E_OK : la valeur transmise pour RoeEventId est valide [SWS_Dcm_00521].
• E_NOT_OK : la valeur de RoeEventId n'est pas valide [SWS_Dcm_00521].

Concurrence et propriétés

L'interface est spécifiée comme réentrante [SWS_Dcm_00521]. Elle peut ainsi être appelée de manière concurrente afin de signaler des événements de manière synchrone au DCM [SWS_Dcm_00521].

La fonction synchrone et réentrante Dcm_StartOfReception ([SWS_Dcm_00094]) est appelée par un module de protocole de transport au début de la réception d'une N-SDU – aussi bien pour les messages simples (Single Frame, SF) que pour les messages segmentés (First Frame, FF). Elle peut être appelée dans un contexte d'interruption ([SWS_Dcm_00094]). L'appel entraîne entre autres l'arrêt du timer S3Server au début de la réception ([SWS_Dcm_00141]).

Les données utiles et les métadonnées sont transmises via info ; pour les connexions génériques, cela permet notamment d'enregistrer SOURCE_ADDRESS_16 ([SWS_Dcm_00848]) et de vérifier TARGET_ADDRESS_16 ([SWS_Dcm_01347]). Si ni charge utile ni métadonnée n'est présente, NULL_PTR est transmis ([SWS_Dcm_00094]). Via bufferSizePtr, la fonction renvoie le tampon disponible pour le calcul de la Block Size (BS) ([SWS_Dcm_00094]). En cas d'acceptation réussie, elle renvoie BUFREQ_OK, à la suite de quoi les données suivantes sont copiées via Dcm_CopyRxData ([SWS_Dcm_00443]).

Les cas d'erreur et de rejet sont signalés par la valeur de retour :

• BUFREQ_E_OVFL : est renvoyé si la longueur demandée TpSduLength est supérieure au tampon disponible dans le DCM ([SWS_Dcm_00094], [SWS_Dcm_00444]). bufferSizePtr reste inchangé ([SWS_Dcm_00094]).
• BUFREQ_E_NOT_OK : est renvoyé si TpSduLength est égal à 0 ([SWS_Dcm_00642]) ou si une requête en cours bloque sur la même connexion ([SWS_Dcm_00557]). Pour une autre connexion, le paramètre DcmDslDiagRespOnSecondDeclinedRequest détermine s'il y a rejet avec BUFREQ_E_NOT_OK ([SWS_Dcm_00790]) ou acceptation avec BUFREQ_OK ([SWS_Dcm_00788]). Les requêtes TesterPresent concurrentes sont également acquittées par BUFREQ_OK ([SWS_Dcm_00557]).

Utilisation

La fonction synchrone Dcm_CopyRxData est appelée pour transmettre les données reçues d'un segment d'I-PDU (N-PDU) à la couche supérieure dans le DCM [SWS_Dcm_00556]. Chaque appel fournit la partie suivante des données d'I-PDU [SWS_Dcm_00556]. L'I-PDU reçue est identifiée via le paramètre id [SWS_Dcm_00556]. Le pointeur info met à disposition le tampon source via SduDataPtr ainsi que le nombre d'octets à copier via SduLength [SWS_Dcm_00556]. Une fois le processus de copie achevé, la taille restante disponible du tampon dans le DCM est signalée via bufferSizePtr [SWS_Dcm_00556], [SWS_Dcm_00443].

Si Dcm_CopyRxData est appelé avec une SduLength de 0, cela sert à la simple interrogation du tampon [SWS_Dcm_00556]. Dans ce cas, SduDataPtr peut être un NULL_PTR ; la fonction renvoie BUFREQ_OK et inscrit la taille restante du tampon de réception dans bufferSizePtr [SWS_Dcm_00556], [SWS_Dcm_00996].

Interaction

Avant la copie, Dcm_StartOfReception doit avoir été complété avec BUFREQ_OK ; les appels suivants de Dcm_CopyRxData copient les données du tampon fourni dans le tampon DCM et mettent à jour bufferSizePtr [SWS_Dcm_00443].

Gestion des erreurs

La fonction renvoie l'état sous forme de BufReq_ReturnType : BUFREQ_OK confirme la copie réussie ou l'interrogation du tampon, tandis que BUFREQ_E_NOT_OK indique qu'aucune donnée n'a été copiée en raison d'une erreur [SWS_Dcm_00556], [SWS_Dcm_00996].

Concurrence et restrictions

Dcm_CopyRxData est spécifié comme réentrant et peut être appelé dans le contexte d'interruption [SWS_Dcm_00556]. L'interface est mise à disposition via Dcm.h [SWS_Dcm_00556].

Utilisation et contexte d'appel

La fonction synchrone Dcm_TpRxIndication est appelée après la réception d'une I-PDU via l'API TP, généralement par le module PduR [SWS_Dcm_00093], [SWS_Dcm_00112]. Elle transmet l'identification de la PDU (id) ainsi que le résultat de la réception (result) et ne renvoie aucune valeur de retour [SWS_Dcm_00093]. La fonction étant réentrante et autorisée à être appelée en contexte d'interruption, les appelants et les états du module doivent être conçus pour gérer la concurrence correspondante [SWS_Dcm_00093].

Comportement en cas de réception erronée

Si Dcm_TpRxIndication est appelée avec une valeur de résultat différente de E_OK, le module Dcm ne doit pas évaluer le tampon alloué à l'I-PDU référencée [SWS_Dcm_00344].

Interaction entre sous-modules

Le sous-module DSL transmet les données reçues au sous-module DSD uniquement si l'appel a été effectué avec la valeur de paramètre result = E_OK [SWS_Dcm_00111]. Des règles spécifiques s'appliquent alors aux requêtes de diagnostic :

• S'il s'agit, pour la requête reçue avec succès (Result = E_OK), de la commande TesterPresent avec suppressPosRspMsgIndicationBit positionné (SID 0x3E, sous-fonction 0x80), le sous-module DSL réinitialise le timer de temporisation de session S3Server [SWS_Dcm_00112].
• Dans ce cas, la requête n'est pas transmise par le sous-module DSL au sous-module DSD pour interprétation ultérieure [SWS_Dcm_00113].

Utilisation et sémantique

La fonction synchrone et réentrante Dcm_CopyTxData est appelée par des modules de la couche inférieure (comme des protocoles de transport) afin de récupérer des données d'un segment d'I-PDU (N-PDU) pour la transmission [SWS_Dcm_00092]. Via le paramètre info, l'appelant transmet le tampon cible SduDataPtr et la longueur en octets souhaitée SduLength. Une valeur de 0 pour SduLength peut être utilisée pour signaler des changements d'état via retry ou pour interroger la quantité de données disponibles ; SduDataPtr peut dans ce cas être un NULL_PTR [SWS_Dcm_00092]. Via availableDataPtr, le DCM signale le nombre d'octets restants dans le tampon d'émission, qui peut être utilisé par les modules TP pour déterminer les tailles de segments suivantes et ne doit pas dépasser le nombre d'octets restant à émettre [SWS_Dcm_00092], [SWS_Dcm_00350].

Gestion de tampon et répétition de transmission

Le paramètre retry permet de contrôler l'acquittement ou la répétition des données [SWS_Dcm_00092] :

• Si retry est un NULL_PTR, les données peuvent être retirées du tampon directement après le processus de copie [SWS_Dcm_00092].
• Avec TP_CONFPENDING, les données précédemment copiées doivent rester dans le tampon TP pour un éventuel traitement d'erreur [SWS_Dcm_00092].
• TP_DATACONF confirme la libération de toutes les données copiées avant cet appel [SWS_Dcm_00092].
• TP_DATARETRY copie à nouveau les données à partir de l'offset TxTpDataCnt par rapport à la position actuelle [SWS_Dcm_00092].

Valeurs de retour et gestion des erreurs

Si les données ont été copiées avec succès et dans leur intégralité, la fonction renvoie BUFREQ_OK [SWS_Dcm_00092], [SWS_Dcm_00346]. Si les données d'émission disponibles sont insuffisantes, aucune opération de copie n'est effectuée et BUFREQ_E_BUSY est renvoyé ; la couche inférieure peut réitérer l'appel ultérieurement [SWS_Dcm_00092]. Si la demande échoue, la fonction renvoie BUFREQ_E_NOT_OK [SWS_Dcm_00092]. Dans ce cas, la demande d'émission issue de PduR_DcmTransmit() n'est pas encore terminée ; seul un appel final de Dcm_TpTxConfirmation met fin au processus et permet de nouvelles transmissions [SWS_Dcm_00350].

concurrence

La fonction est réentrante et peut également être appelée dans le contexte d'interruption [SWS_Dcm_00092].

La fonction de rappel Dcm_TpTxConfirmation ([SWS_Dcm_00351]) est appelée de manière synchrone par la couche de transport inférieure après qu'une I-PDU de diagnostic a été transmise sur le réseau. Le paramètre id permet d'identifier l'I-PDU concernée, tandis que result signale la réussite ou l'échec de l'opération d'émission ([SWS_Dcm_00351]). La fonction n'a aucune valeur de retour, est réentrante et peut explicitement être exécutée dans un contexte d'interruption ([SWS_Dcm_00351]).

Lors de l'appel de Dcm_TpTxConfirmation, le module DCM procède à des nettoyages et à des transitions d'état centraux :

• Le tampon d'émission associé est déverrouillé ([SWS_Dcm_00352]).
• Les surveillances d'erreur en cours, telles que les temporisations de page buffer ainsi que les temporisations P2ServerMax et P2*ServerMax, sont arrêtées ([SWS_Dcm_00353]).
• La DcmPduId de la connexion, bloquée depuis la réception (Dcm_TpRxIndication), est libérée afin de permettre la réception des requêtes suivantes ([SWS_Dcm_00241]).
• Le protocole actif n'est pas terminé par la confirmation de la réponse DSL (aucun appel de xxx_StopProtocol) ([SWS_Dcm_00624]).

En cas d'erreur (lorsque result signale une erreur ou qu'une interruption est confirmée après l'échec de Dcm_CopyTxData), [SWS_Dcm_00350] exige impérativement cet appel terminal pour clôturer formellement l'ordre d'émission et permettre de nouvelles transmissions via PduR_DcmTransmit(). En cas de confirmation erronée, le sous-module DSD ne doit pas réémettre la réponse de diagnostic ([SWS_Dcm_00118]).

De plus, la confirmation d'une réponse (autre que NRC 0x78) marque la fin régulière d'une requête de diagnostic ([SWS_Dcm_01378]). Après la confirmation d'une réponse positive à un EcuReset, le DCM ignore toute nouvelle requête pendant le traitement de réinitialisation ([SWS_Dcm_00834]).

Utilisation

L'interface synchrone Dcm_TxConfirmation (ID de service 0x40, déclarée dans Dcm.h) est appelée conformément à [SWS_Dcm_01092] par le module d'interface de communication sous-jacent pour confirmer l'envoi d'une PDU ou pour signaler l'échec de la transmission. La fonction ne possède pas de valeur de retour et traite deux paramètres d'entrée :

• TxPduId : identifiant (PduIdType) de la PDU envoyée.
• result : statut de la transmission (Std_ReturnType). Les valeurs valides sont E_OK en cas de transmission réussie ainsi que E_NOT_OK si la transmission de la PDU a échoué.

Traitement des erreurs et notification d'état

Le résultat de la transmission est directement signalé au DCM via le paramètre result ([SWS_Dcm_01092]). Aucun message d'erreur spécifique DET ou DEM n'est défini pour cette fonction dans l'extrait de spécification fourni.

Concurrence et contexte d'appel

Concernant la réentrance, Dcm_TxConfirmation est réentrante pour des appels avec des ID de PDU différents, mais non réentrante pour la même TxPduId ([SWS_Dcm_01092]). Il convient de noter que l'appel par le module sous-jacent peut avoir lieu dans un contexte d'interruption ([SWS_Dcm_01092]).

Interaction

Dans le cas d'une transmission périodique (PeriodicTransmission), le DCM est appelé conformément à [SWS_Dcm_01073] via Dcm_TxConfirmation afin de se voir notifier le résultat d'émission respectif.

La fonction synchrone et réentrante Dcm_ComM_NoComModeEntered (Service-ID 0x21) informe le module DCM du passage d'un réseau de communication à l'état COMM_NO_COMMUNICATION [SWS_Dcm_00356]. L'interface est fournie via l'en-tête Dcm_ComM.h, ne possède pas de valeur de retour et identifie le réseau concerné via le paramètre d'entrée NetworkId de type uint8 [SWS_Dcm_00356].

Lors de cet appel, le DCM coupe toute communication sur le réseau spécifié, désactivant ainsi complètement tant la réception que l'émission de messages [SWS_Dcm_00148]. Cela inclut obligatoirement les modes de transmission suivants :

• blocage des transmissions ResponseOnEvent [SWS_Dcm_00149],
• désactivation des transmissions périodiques via ReadDataByPeriodicIdentifier (periodicId) [SWS_Dcm_00150] ainsi que
• coupure des transmissions normales [SWS_Dcm_00151].

Par conséquent, après l'exécution de Dcm_ComM_NoComModeEntered, le module DCM ne doit plus appeler la fonction PduR PduR_DcmTransmit() pour ce contexte [SWS_Dcm_00152].

Si la fonction est appelée avec un NetworkId qui ne correspond à aucun canal ComM référencé dans le DCM via le paramètre de configuration DcmDslProtocolComMChannelRef, le module DCM n'exécute aucune action et retourne immédiatement [SWS_Dcm_01324].

La fonction synchrone et réentrante Dcm_ComM_SilentComModeEntered ([SWS_Dcm_00358]) sert à informer le module DCM du passage d'un réseau de communication à l'état COMM_SILENT_COMMUNICATION. L'interface possède le Service-ID 0x22, ne renvoie aucune valeur de retour et attend comme paramètre d'entrée NetworkId l'identifiant du réseau concerné ([SWS_Dcm_00358]). Elle est mise à disposition via le fichier d'en-tête Dcm_ComM.h ([SWS_Dcm_00358]).

Dès que cet appel intervient, le DCM doit interrompre totalement l'ensemble des activités d'émission sur le canal réseau concerné ([SWS_Dcm_00153]). Cela comprend en détail les mesures suivantes :

• la désactivation de toutes les transmissions normales ([SWS_Dcm_00156]),
• le blocage des transmissions Response-on-Event ([SWS_Dcm_00154]) ainsi que
• la désactivation des émissions périodiques dans le cadre de ReadDataByPeriodicIdentifier ([SWS_Dcm_00155]).

Concernant le traitement des erreurs et les conditions aux limites, il est défini que le DCM doit retourner sans aucune autre action si le NetworkId transmis correspond à un canal ComM qui n'est pas référencé dans le DCM via le paramètre de configuration DcmDslProtocolComMChannelRef ([SWS_Dcm_01325]). Aucune erreur de développement spécifique ni aucune valeur de retour d'erreur n'est spécifiée pour cet appel.

Interprétation : l'appel devrait typiquement être effectué par le module ComM dès que la transition vers le mode de communication silencieux est accomplie. Question Q-fc9b6303ae0c0e41 (ouverte)

La fonction synchrone et réentrante Dcm_ComM_FullComModeEntered est mise à disposition via le fichier d'en-tête Dcm_ComM.h et informe le module DCM du passage d'un réseau de communication à l'état COMM_FULL_COMMUNICATION [SWS_Dcm_00360]. Le paramètre d'entrée utilisé est NetworkId, qui identifie le réseau concerné par le changement de mode [SWS_Dcm_00360].

L'appel active toute communication pour ce réseau, de sorte que tant la réception que l'émission de messages sont autorisées [SWS_Dcm_00157]. Cela inclut les modes de transmission suivants :

• transmissions normales [SWS_Dcm_00161],
• transmissions Response-on-Event [SWS_Dcm_00159] ainsi que
• transmissions périodiques au moyen de ReadDataByPeriodicIdentifier [SWS_Dcm_00160].

Dès que Dcm_ComM_FullComModeEntered a été appelée, le DCM traite les fonctions internes DslInternal_ResponseOnOneDataByPeriodicId() et DslInternal_ResponseOnOneEvent() sans restriction [SWS_Dcm_00162]. Sur le plan chronologique, le DCM doit attendre cet appel avant d'engager la transmission d'une réponse de diagnostic ; le temps d'attente ne doit pas dépasser P2ServerMax à compter de la réception de la requête [SWS_Dcm_01142].

En cas d'erreur, lorsque le NetworkId transmis concerne un canal ComM qui n'est pas configuré dans le DCM (paramètre DcmDslProtocolComMChannelRef), la fonction retourne immédiatement et sans autre action [SWS_Dcm_01326].

Utilisation et sémantique

La fonction de callback synchrone et réentrante Dcm_CsmAsyncJobFinished est appelée par le Crypto Service Manager (CSM) dès qu'un traitement de tâche asynchrone est achevé [SWS_Dcm_91076]. En guise de paramètre d'entrée, elle reçoit via result de type Csm_ResultType le résultat du travail CSM terminé [SWS_Dcm_91076]. En tant que valeur de retour, la fonction renvoie toujours E_OK [SWS_Dcm_91076].

Configuration et conditions limites

Les intégrateurs doivent configurer le nom de cette fonction dans la configuration ECUC du CSM en tant que callback pour les tâches asynchrones [SWS_Dcm_91076]. Un seul callback de ce type est disponible pour le DCM ; l'identification de la tâche terminée s'effectue, d'après la spécification, par évaluation du paramètre de travail [SWS_Dcm_91076]. Toutefois, étant donné que la signature de la fonction C transmet uniquement result, le DCM devrait déterminer la tâche correspondante en interne via l'état de transaction de l'authentification en cours. Question Q-04ad1d5fb514f467 (ouverte)

L'interface n'est disponible que si le paramètre DcmDspAuthenticationConnection est défini dans la configuration (différent de null) [SWS_Dcm_91076]. Aucun traitement d'erreur spécifique ni notification DET n'est spécifié pour cet appel, car la valeur de retour est invariablement E_OK [SWS_Dcm_91076].

La fonction de callback synchrone et réentrante Dcm_KeyMAsyncCertificateVerifyFinished est appelée par le module KeyM à l'issue d'une vérification asynchrone de certificat [SWS_Dcm_91077]. Elle informe le DCM de l'achèvement ainsi que du résultat du processus de vérification et renvoie toujours E_OK comme valeur de retour [SWS_Dcm_91077].

Paramètres et fonctionnement

• CertID : identifiant du certificat dont la vérification a été achevée. À l'aide de cet identifiant, le DCM détermine quelle tâche de vérification s'est terminée [SWS_Dcm_91077].
• Result : valeur de retour et statut de la tâche de vérification asynchrone issus du KeyM [SWS_Dcm_91077].

Configuration et conditions limites

Les intégrateurs doivent configurer ce nom de fonction dans la configuration ECUC du KeyM en tant que callback pour les tâches asynchrones [SWS_Dcm_91077]. Comme un seul callback est disponible pour cette notification, le DCM doit nécessairement résoudre le certificat respectif via le paramètre CertID [SWS_Dcm_91077].

L'interface est exclusivement disponible lorsque le paramètre de configuration DcmDspAuthenticationConnection est configuré dans le chemin Dcm/DcmDsp/DcmDspAuthentication (!= null) [SWS_Dcm_91077]. Aucun code d'erreur particulier ni message DET n'est spécifié pour cet appel [SWS_Dcm_91077].

La fonction de callout Dcm_ReadMemory ([SWS_Dcm_00539]), déclarée dans Dcm_Externals.h, sert au DCM à lire des données de mémoire serveur sur la base de l'adresse de début (MemoryAddress) et de la taille en octets (MemorySize). La fonction est requise pour les services UDS ReadMemoryByAddress (0x23) ([SWS_Dcm_00495]), ReadDataByIdentifier (0x22) pour les DID dynamiques dans la plage d'adresses 0xF200 à 0xF3FF ([SWS_Dcm_00653]), RequestUpload ainsi que TransferData ([SWS_Dcm_00539]). Si le paramètre MemoryIdentifier n'est pas utilisé, il doit être défini à 0 ([SWS_Dcm_00539]).

L'interface est asynchrone et non réentrante ([SWS_Dcm_00539]). L'état d'appel est transmis via OpStatus avec les valeurs DCM_INITIAL, DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK. Tant que l'opération de lecture se poursuit, la fonction renvoie DCM_READ_PENDING ([SWS_Dcm_00985]). Si l'appel retourne DCM_READ_FORCE_RCRRP, le DCM déclenche immédiatement l'envoi d'un message RCR-RP (NRC 0x78) et suspend les appels ultérieurs jusqu'à la confirmation d'envoi ([SWS_Dcm_00839]). Après confirmation du RCR-RP, le DCM appelle à nouveau la fonction issue de Dcm_MainFunction avec OpStatus = DCM_FORCE_RCRRP_OK ([SWS_Dcm_00840]).

En cas de succès, les données lues sont écrites dans le tampon MemoryData et DCM_READ_OK est retourné ([SWS_Dcm_00539], [SWS_Dcm_00985]). Si l'opération échoue, la fonction renvoie DCM_READ_FAILED et positionne ErrorCode. Le DCM transmet ensuite une réponse négative avec la valeur NRC correspondante ([SWS_Dcm_00644]).

La fonction de callout Dcm_WriteMemory, déclarée dans Dcm_Externals.h, est appelée par le DCM de manière asynchrone et non réentrante afin d'écrire des données en mémoire sur la base d'une adresse de début et d'une taille en octets [SWS_Dcm_00540]. Elle sert à l'implémentation des services UDS WriteMemoryByAddress (0x3D), RequestDownload et TransferData [SWS_Dcm_00540]. À la réception de WriteMemoryByAddress, le DCM n'appelle le callout qu'après vérification de la requête [SWS_Dcm_00491].

Pour contrôler le déroulement, OpStatus est transmis (valeurs possibles : DCM_INITIAL, DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK) [SWS_Dcm_00540]. Les paramètres MemoryAddress et MemorySize déterminent la zone mémoire cible, tandis que MemoryData pointe vers le tampon de diagnostic du DCM [SWS_Dcm_00540]. Si MemoryIdentifier ou MemoryAddress ne sont pas utilisés (par exemple pour des données compressées), ils doivent être fixés à 0 [SWS_Dcm_00540].

La valeur de retour Dcm_ReturnWriteMemoryType [SWS_Dcm_00986] définit la suite du traitement dans le DCM :

• DCM_WRITE_OK : l'opération d'écriture a réussi [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_PENDING : l'opération n'est pas encore terminée et nécessite des appels consécutifs [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_FORCE_RCRRP : le DCM initie immédiatement l'envoi d'une Response Pending (NRC 0x78) et suspend les appels suivants jusqu'à la confirmation d'envoi [SWS_Dcm_00837]. Ensuite, le nouvel appel issu de Dcm_MainFunction s'effectue avec DCM_FORCE_RCRRP_OK [SWS_Dcm_00838].
• DCM_WRITE_FAILED : en cas d'erreur, le DCM envoie une réponse négative avec la valeur NRC transmise via le paramètre de sortie ErrorCode [SWS_Dcm_00540], [SWS_Dcm_00643].

La fonction de callout Dcm_SetProgConditions permet à l'intégrateur de sauvegarder de manière persistante les informations pertinentes avant un passage dans le bootloader ou une réinitialisation consécutive à une demande ECUReset [SWS_Dcm_00543]. Les données de contexte pertinentes sont transmises via un pointeur vers la structure Dcm_ProgConditionsType, qui regroupe entre autres des adresses source de connexion et de testeur, des identifiants de service et de sous-fonction ainsi que des flags de commande tels que ReprogramingRequest et ResponseRequired [SWS_Dcm_00988]. Lors de la réception d'un service UDS 0x10 avec sous-fonction 0x02, le DCM positionne ces flags et appelle l'interface [SWS_Dcm_01182].

L'appel s'effectue de manière asynchrone et n'est pas réentrant (Non Reentrant) [SWS_Dcm_00543]. Les états DCM_INITIAL, DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK sont commandés via le paramètre OpStatus [SWS_Dcm_00543]. Dans la mesure où l'exécution se poursuit et où la fonction renvoie DCM_E_PENDING, le DCM appelle à nouveau l'interface lors du cycle de fonction principale suivant afin d'achever la configuration [SWS_Dcm_00543], [SWS_Dcm_01184]. L'émission d'une réponse de type Response Pending (NRC 0x78) peut être forcée au moyen de DCM_E_FORCE_RCRRP [SWS_Dcm_00543]. Selon la configuration, l'appel par le DCM n'a lieu qu'après transmission réussie du NRC 0x78 [SWS_Dcm_00535].

Si les conditions ont été définies sans erreur et que le callout renvoie E_OK, le DCM amorce le changement de mode du ModeDeclarationGroupPrototype DcmEcuReset vers EXECUTE [SWS_Dcm_00719], [SWS_Dcm_01163], [SWS_Dcm_01180]. En revanche, si l'état ne peut pas être sauvegardé et que la fonction répond avec E_NOT_OK, la réinitialisation ainsi que le saut dans le bootloader n'ont pas lieu, le changement de mode est bloqué et le DCM transmet la réponse négative NRC 0x22 (Conditions not correct) [SWS_Dcm_00715], [SWS_Dcm_01181].

La fonction de callout Dcm_GetProgConditions avec le service ID 0x62 est appelée pendant l'initialisation du DCM pour déterminer si une réponse de diagnostic en attente au service $50 ou $51 doit être envoyée [SWS_Dcm_00544]. La déclaration de l'interface est mise à disposition via le fichier d'en-tête Dcm_Externals.h [SWS_Dcm_00544].

Utilisation et paramètres

L'exécution de la fonction s'effectue de manière synchrone, sans qu'aucun paramètre d'entrée ou d'entrée/sortie standard ne soit transmis [SWS_Dcm_00544] :

• Paramètre de sortie : via le pointeur ProgConditions de type Dcm_ProgConditionsType*, le callout renvoie les conditions dans lesquelles le saut précédent depuis le chargeur d'amorçage a été demandé [SWS_Dcm_00544]. Les paramètres de contexte pertinents sont consignés dans le type de données Dcm_ProgConditionsType [SWS_Dcm_00544].
• Valeur de retour : la fonction renvoie une valeur d'état de type Dcm_EcuStartModeType à l'appelant [SWS_Dcm_00544].

Concurrence et traitement des erreurs

La fonction est classée comme non réentrante (Non Reentrant) et ne doit donc pas être exécutée de manière concurrente [SWS_Dcm_00544]. Pour ce callout, aucun code d'erreur spécifique pour DET ou DEM n'est défini dans la spécification d'interface [SWS_Dcm_00544].

La fonction de callout Dcm_ProcessRequestAddFile est appelée par le DCM afin d'initier le service RequestFileTransfer avec le mode de fonctionnement 0x01 (AddFile) ([SWS_Dcm_91078]). Elle est disponible via Dcm_Externals.h, possède l'ID de service 0x72 et est spécifiée comme non réentrante (Non Reentrant) ainsi qu'asynchrone ([SWS_Dcm_91078]).

Le contrôle du déroulement de l'appel asynchrone s'effectue via le paramètre OpStatus :

• DCM_INITIAL : tous les paramètres d'entrée sont valides. En font partie le chemin et le nom du fichier (filePathAndName avec filePathAndNameLength), l'octet dataFormatIdentifier (quartet haut pour la compression, quartet bas pour le chiffrement) ainsi que la taille non compressée et compressée du fichier (fileSizeUncompressed, fileSizeCompressed) ([SWS_Dcm_91078]).
• DCM_PENDING, DCM_CANCEL et DCM_FORCE_RCRRP_OK : lors de ces appels ultérieurs, tous les paramètres d'entrée sont définis sur 0x00 ([SWS_Dcm_91078]).

En guise de valeurs de retour, la fonction fournit E_OK en cas d'exécution réussie, DCM_E_PENDING en cas de traitement toujours en cours ou DCM_E_FORCE_RCRRP lorsque l'application demande l'envoi d'une réponse provisoire (NRC 0x78) ([SWS_Dcm_91078], [SWS_Dcm_91086]). En cas de succès, maxNumberOfBlockLength définit la longueur de bloc maximale admissible des futurs messages TransferData, sans SID ni compteur de blocs ([SWS_Dcm_91078]).

En cas d'erreur, la fonction renvoie E_NOT_OK. Dans ce cas, un code de réponse négatif (NRC) doit être transmis via le paramètre ErrorCode, que le DCM envoie au client dans une réponse de diagnostic négative ([SWS_Dcm_91078]). Si la configuration DcmRequestFileTransferUsePort est activée, cette fonctionnalité est alternativement mise à disposition sous la forme d'une opération de port ProcessRequestAddFile de l'interface RequestFileTransfer ([SWS_Dcm_91086]).

Utilisation et sémantique d'appel

La fonction de callout Dcm_ProcessRequestDeleteFile est appelée par le DCM afin d'initier, dans le cadre du service de diagnostic RequestFileTransfer, la suppression d'un fichier (modeOfOperation = 0x02) sur le serveur [SWS_Dcm_91079]. La fonction est déclarée dans Dcm_Externals.h et fonctionne de manière asynchrone et non réentrante (Non Reentrant) [SWS_Dcm_91079].

La transmission et l'évaluation s'effectuent à l'aide du paramètre OpStatus :

• DCM_INITIAL : indique le début de l'opération. Tous les paramètres d'entrée sont ici valides ; filePathAndName transmet l'emplacement de stockage et le nom du fichier à supprimer, dont la longueur en octets est spécifiée via filePathAndNameLength [SWS_Dcm_91079].
• DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK : en cas de traitement continu ou d'interruption, tous les paramètres d'entrée sont définis sur 0x00 [SWS_Dcm_91079].

En guise de valeurs de retour, la fonction fournit E_OK en cas d'exécution réussie, DCM_E_PENDING si l'exécution est toujours en cours et nécessite d'autres appels, ou DCM_E_FORCE_RCRRP si l'application requiert l'envoi d'un message intermédiaire avec NRC 0x78 (Response Pending) [SWS_Dcm_91079], de manière analogue au service RequestFileTransfer [SWS_Dcm_91086].

Gestion des erreurs

Si le traitement échoue, la fonction renvoie E_NOT_OK. Dans ce cas, un code de réponse négatif doit être mis à disposition via le paramètre de sortie ErrorCode, que le DCM transmet au testeur sous la forme d'une notification négative (NRC) [SWS_Dcm_91079].

La fonction de callout Dcm_ProcessRequestReplaceFile est appelée par le DCM afin d'initier un processus de diagnostic pour RequestFileTransfer avec le mode de fonctionnement 0x03 (ReplaceFile) [SWS_Dcm_91080]. La fonction est définie comme non réentrante (Non Reentrant) et asynchrone, et elle est fournie via l'en-tête Dcm_Externals.h [SWS_Dcm_91080].

Le contrôle du déroulement du traitement asynchrone s'effectue via le paramètre OpStatus :

• Lors de l'appel initial avec DCM_INITIAL, le DCM transmet tous les paramètres d'entrée valides, parmi lesquels le chemin et le nom de fichier (filePathAndName avec indication de longueur filePathAndNameLength), l'identifiant pour la compression et le chiffrement (dataFormatIdentifier) ainsi que la taille de fichier non compressée et compressée (fileSizeUncompressed, fileSizeCompressed) [SWS_Dcm_91080].
• Lors d'appels ultérieurs ou d'une interruption (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK), tous les paramètres d'entrée sont définis sur 0x00 [SWS_Dcm_91080].
• En cas de succès, la fonction renvoie au DCM, via le paramètre de sortie maxNumberOfBlockLength, la longueur maximale de données utiles pour les requêtes TransferData ultérieures (sans SID ni compteur de séquence de bloc) [SWS_Dcm_91080].

Sont prévues comme valeurs de retour E_OK en cas d'exécution réussie, DCM_E_PENDING en cas de traitement encore en cours et DCM_E_FORCE_RCRRP pour demander un retour de type Response Pending (NRC 0x78) [SWS_Dcm_91080], [SWS_Dcm_91086]. Si l'exécution échoue, la fonction renvoie E_NOT_OK et assigne au paramètre ErrorCode le code de réponse de diagnostic négatif (NRC) correspondant, que le DCM transmet au testeur [SWS_Dcm_91080].

La fonction de callout Dcm_ProcessRequestReadFile est appelée par le DCM pour démarrer un processus de transfert de fichier (service RequestFileTransfer) avec le mode de fonctionnement ReadFile (modeOfOperation 0x04) [SWS_Dcm_91081]. La fonction est déclarée dans l'en-tête Dcm_Externals.h, fonctionne de manière asynchrone et n'est pas réentrante (Non Reentrant) [SWS_Dcm_91081].

L'appel s'effectue via le paramètre d'état OpStatus : lors de l'appel initial DCM_INITIAL, tous les paramètres d'entrée sont valides, tandis qu'ils sont définis sur 0x00 lors des appels ultérieurs avec DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK [SWS_Dcm_91081]. L'application reçoit le chemin et le nom de fichier via filePathAndName (longueur dans filePathAndNameLength), le format de compression et de chiffrement via dataFormatIdentifier ainsi que les tailles de fichier via fileSizeUncompressed et fileSizeCompressed [SWS_Dcm_91081]. En tant que paramètre de sortie, l'application doit renseigner maxNumberOfBlockLength avec le nombre maximal d'octets pour les réponses TransferData ultérieures (sans SID ni compteur de séquence de bloc) [SWS_Dcm_91081].

Sont définies comme valeurs de retour de Std_ReturnType : E_OK en cas d'exécution réussie, DCM_E_PENDING lorsque le traitement asynchrone est encore en cours ou DCM_E_FORCE_RCRRP pour demander une réponse « Response Pending » (NRC 0x78) [SWS_Dcm_91081]. Si l'opération échoue, elle renvoie E_NOT_OK ; dans ce cas, le DCM transmet au testeur une réponse négative avec la valeur de NRC définie dans le paramètre de sortie ErrorCode [SWS_Dcm_91081]. L'interaction correspond au déroulement général du service RequestFileTransfer, tel qu'il est configuré de façon analogue pour d'autres opérations sur fichiers telles que ProcessRequestAddFile [SWS_Dcm_91086].

Utilisation

La fonction de callout Dcm_ProcessRequestReadDir est déclarée via le fichier d'en-tête Dcm_Externals.h et est appelée par le DCM pour démarrer de manière asynchrone le service RequestFileTransfer avec le mode de fonctionnement 0x05 (ReadDir) [SWS_Dcm_91082]. La progression du traitement est contrôlée via le paramètre de transmission OpStatus [SWS_Dcm_91082]. Lors du premier appel avec DCM_INITIAL, le DCM transmet le chemin ou le nom via filePathAndName avec la longueur en octets filePathAndNameLength [SWS_Dcm_91082]. Lors des appels ultérieurs ou en cas d'interruption (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK), tous les paramètres d'entrée sont définis sur 0x00 [SWS_Dcm_91082].

En guise de valeurs de sortie, l'application doit fournir la taille des données de répertoire via dirInfoLength et la taille de bloc maximale admissible pour les transferts ultérieurs via maxNumberOfBlockLength [SWS_Dcm_91082]. En plus de E_OK en cas d'exécution réussie, la fonction peut renvoyer DCM_E_PENDING si l'opération est encore en cours, ou DCM_E_FORCE_RCRRP pour déclencher l'envoi d'une réponse intermédiaire (NRC 0x78) [SWS_Dcm_91082].

Gestion des erreurs

Si une erreur survient, la fonction doit renvoyer E_NOT_OK. Dans ce cas, le DCM lit le paramètre ErrorCode et transmet sa valeur au testeur en tant que code de réponse négatif (NRC) [SWS_Dcm_91082]. Aucun message DET ou DEM spécifique n'est prévu pour l'interface ; les vérifications d'erreur sur le chemin transmis devraient par conséquent incomber entièrement à l'implémentation propre à l'application. Question Q-278dbc3db7b4363b (ouverte)

Concurrence et interaction

La fonction est spécifiée comme non réentrante (Non Reentrant) et ne doit donc pas être appelée simultanément pour plusieurs requêtes de diagnostic [SWS_Dcm_91082]. Elle fait partie du groupe d'interfaces du service RequestFileTransfer, dont l'intégration peut être influencée par des paramètres de configuration [SWS_Dcm_91086].

Utilisation et contexte d'appel

La fonction de callout Dcm_WriteFile est appelée par le DCM lorsque des données sont reçues via le service UDS TransferData (0x36) et qu'un processus de téléchargement préalablement démarré au moyen de RequestFileTransfer avec les modes 0x01 (AddFile) ou 0x03 (ReplaceFile) est actif [SWS_Dcm_01444]. L'interface est disponible via Dcm_Externals.h [SWS_Dcm_91083].

L'affectation des paramètres dépend de l'état de progression OpStatus [SWS_Dcm_91083] :

• DCM_INITIAL : tous les paramètres d'entrée sont valides. Le pointeur Data référence les données utiles à écrire, et DataLength indique leur longueur en octets. La valeur de DataLength ne dépasse pas la longueur de bloc maximale précédemment négociée lors de Dcm_ProcessRequestFileTransfer (NumberOfBlockLength).
• DCM_PENDING, DCM_CANCEL et DCM_FORCE_RCRRP_OK : tous les paramètres d'entrée sont définis sur 0x00.

Sémantique asynchrone et valeurs de retour

La fonction fonctionne de manière asynchrone et non réentrante (Non Reentrant) [SWS_Dcm_91083]. Elle fournit les valeurs d'état suivantes :

• E_OK : l'opération d'écriture a été achevée avec succès.
• DCM_E_PENDING : le traitement n'est pas encore terminé et nécessite d'autres appels.
• DCM_E_FORCE_RCRRP : l'application demande l'envoi d'une réponse d'attente (Response Pending, NRC 0x78).
• E_NOT_OK : l'opération a échoué.

Gestion des erreurs

Si Dcm_WriteFile renvoie la valeur E_NOT_OK, le module DCM envoie une réponse UDS négative dont le NRC correspond à la valeur fournie via le paramètre de sortie ErrorCode [SWS_Dcm_91083].

La fonction de callout Dcm_ReadFileOrDir est appelée par le module DCM lorsqu'une requête conforme au format pour le service UDS TransferData (0x36) est reçue dans le cadre d'un téléversement de fichier ou de répertoire en cours (préalablement démarré via le service UDS RequestFileTransfer avec le mode 0x04 pour ReadFile ou 0x05 pour ReadDir) [SWS_Dcm_01445]. La fonction sert à fournir les données à envoyer en guise de réponse au client [SWS_Dcm_91085]. La déclaration d'interface est disponible via l'en-tête Dcm_Externals.h [SWS_Dcm_91085].

L'exécution est asynchrone et spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_91085]. L'interaction et l'affectation des paramètres dépendent de l'état de fonctionnement transmis :

• État de fonctionnement (OpStatus) : lors de l'appel initial avec DCM_INITIAL, tous les paramètres d'entrée sont valides. Lors d'appels consécutifs ou d'interruption avec DCM_PENDING, DCM_CANCEL ou DCM_FORCE_RCRRP_OK, tous les paramètres d'entrée sont définis sur 0x00 [SWS_Dcm_91085].
• Tampon et longueur de bloc : le paramètre DataLength transmet en entrée la longueur de bloc maximale autorisée (correspondant à la valeur maxNumberOfBlockLength signalée au client) et renvoie en sortie la longueur en octets effectivement fournie dans Data, qui ne doit pas dépasser la valeur d'entrée [SWS_Dcm_91085]. Interprétation : bien que Data soit formellement déclaré comme paramètre d'entrée dans l'interface, il devrait servir à transmettre les données utiles à lire. Question Q-53de8a0bdbc4a2b4 (ouverte)
• Valeurs de retour : l'opération renvoie E_OK en cas de mise à disposition réussie des données, DCM_E_PENDING lorsque le traitement n'est pas encore terminé ou DCM_E_FORCE_RCRRP si l'application souhaite forcer l'envoi d'un message intermédiaire (Response Pending, NRC 0x78) [SWS_Dcm_91085].

En cas d'échec du traitement dans l'application, E_NOT_OK est renvoyé. Dans ce cas d'erreur, le module DCM transmet une réponse UDS négative (NRC) au client, dont le code d'erreur correspond à la valeur définie dans le paramètre de sortie ErrorCode [SWS_Dcm_91085].

La fonction Dcm_MainFunction sert au traitement des tâches centrales de la boucle principale du Diagnostic Communication Manager ([SWS_Dcm_00053]). Elle possède la signature void Dcm_MainFunction(void) et ne fournit aucune valeur de retour. Comme elle est mise à disposition via l'en-tête SchM_Dcm.h, son appel devrait vraisemblablement s'effectuer de manière cyclique dans le contexte d'une tâche d'ordonnanceur du logiciel de base. Question Q-e083a72aae447ab5 (ouverte)

Une tâche essentielle est le contrôle et la poursuite inter-cycles des processus asynchrones :

• Si une opération avec Dcm_OpStatusType renvoie la valeur de retour DCM_E_PENDING, le DCM appelle à nouveau l'opération à chaque appel de Dcm_MainFunction avec OpStatus = DCM_PENDING tant que cet état persiste ([SWS_Dcm_00530]).
• Si Dem_ClearDTC() renvoie l'état DEM_PENDING, la fonction est à nouveau appelée au cycle suivant de Dcm_MainFunction ; le DCM envoie au besoin le NRC 78 (ResponsePending) ([SWS_Dcm_00703]).
• Les appels de Dem_SetDTCFilter() avec le paramètre FilterForFault-DetectionCounter défini doivent impérativement avoir lieu dans le contexte de Dcm_MainFunction ([SWS_Dcm_00519]).
• Après confirmation d'une transmission RCR-RP, le DCM appelle à nouveau des opérations telles que Dcm_WriteMemory ou Dcm_ReadMemory depuis Dcm_MainFunction avec OpStatus = DCM_FORCE_RCRRP_OK ([SWS_Dcm_00529], [SWS_Dcm_00838], [SWS_Dcm_00840]).
• Si la valeur DCM_E_PENDING est signalée lors de Xxx_GetSecurityAttemptCounter, l'appel est interrompu et poursuivi au cycle suivant ([SWS_Dcm_01351]) ; en cas de dépassement du délai d'attente configuré, le DCM interrompt l'opération en attente avec OpStatus = DCM_CANCEL ([SWS_Dcm_01352]).

La fonction Xxx_GetSeed (fournie via Dcm_Externals.h) sert à la mise à disposition asynchrone d'une valeur de seed par l'application pour le module DCM [SWS_Dcm_01151]. Elle est appelée dès qu'une requête UDS du service SecurityAccess (0x27) avec le type de sous-fonction « requestSeed » est reçue et que le niveau de sécurité demandé n'est pas encore actif [SWS_Dcm_00862], [SWS_Dcm_00324].

Contexte d'appel et paramètres

L'interface est définie comme non réentrante (Non Reentrant) et opère de manière asynchrone [SWS_Dcm_01151] :

• SecurityAccessDataRecord : pointeur vers des données d'entrée supplémentaires pour le calcul du seed ; la taille minimale est d'un octet selon DcmDspSecurityADRSize [SWS_Dcm_01151].
• OpStatus : indique l'état actuel de l'opération asynchrone [SWS_Dcm_01151].
• Seed : pointeur de sortie par lequel l'application fournit le seed calculé [SWS_Dcm_01151].
• ErrorCode : paramètre de sortie pour le renvoi d'un code d'erreur négatif (NRC) [SWS_Dcm_01151].

Valeurs de retour et gestion des erreurs

• E_OK : le seed a été déterminé et fourni avec succès [SWS_Dcm_01151].
• DCM_E_PENDING : le calcul n'est pas encore terminé ; des calculs ou appels ultérieurs sont nécessaires pour l'achèvement [SWS_Dcm_01151].
• E_NOT_OK : la requête a échoué. Dans ce cas, le module DCM envoie une réponse négative UDS avec la valeur de NRC transmise dans le paramètre ErrorCode [SWS_Dcm_01151], [SWS_Dcm_00659].

Remarques d'intégration

Selon la configuration de DcmDspSecurityUsePort, l'intégration s'effectue sous forme de fonction C pour USE_ASYNCH_FNC (référencée via DcmDspSecurityGetSeedFnc) [SWS_Dcm_00862] ou sous forme d'opération Rte pour USE_ASYNCH_CLIENT_SERVER [SWS_Dcm_00324]. Si aucune donnée d'accès supplémentaire ne doit être transmise, la signature de fonction alternative sans le paramètre SecurityAccessDataRecord est utilisée [SWS_Dcm_91003].

La fonction Xxx_GetSeed sert d’interface asynchrone du module DCM vers l’application afin de fournir une valeur de seed lors d’une requête de type « requestSeed » dans le cadre du service UDS SecurityAccess (0x27) [SWS_Dcm_91003], [SWS_Dcm_00862]. L’appel est effectué par le sous-module DSP du DCM, tant que le niveau de sécurité n’est pas encore actif et que la configuration prévoit USE_ASYNCH_CLIENT_SERVER ou USE_ASYNCH_FNC [SWS_Dcm_00324], [SWS_Dcm_00862].

L’interface est implémentée de manière asynchrone et non réentrante (Non Reentrant) [SWS_Dcm_91003]. Le contrôle de la progression du traitement s’effectue via le paramètre d’entrée OpStatus (type Dcm_OpStatusType) [SWS_Dcm_91003]. Comme valeurs de retour sont définies E_OK en cas de mise à disposition réussie, E_NOT_OK en cas d’erreur ainsi que DCM_E_PENDING lorsque la génération de la seed se poursuit et que d’autres appels sont nécessaires [SWS_Dcm_91003]. La valeur générée est transmise via le pointeur Seed (tampon Inout/Out) [SWS_Dcm_91003].

Si l’opération échoue et que Xxx_GetSeed retourne E_NOT_OK, le module DCM doit émettre une réponse négative (NRC) avec le code d’erreur défini via le paramètre de sortie ErrorCode (Dcm_NegativeResponseCodeType) [SWS_Dcm_91003], [SWS_Dcm_00659]. Le service est déclaré via le fichier d’en-tête Dcm_Externals.h [SWS_Dcm_91003].

La fonction Xxx_CompareKey est appelée par le Diagnostic Communication Manager ([SWS_Dcm_91004]) de manière asynchrone et non réentrante afin de comparer une clé reçue, dans le cadre du service UDS SecurityAccess (0x27, sous-fonction sendKey), avec la logique interne de l'application ([SWS_Dcm_00863]). Elle est utilisée lorsque le statut d'accès n'est pas encore actif, que la requête de seed a réussi et que le paramètre de configuration DcmDspSecurityUsePort est positionné sur USE_ASYNCH_CLIENT_SERVER ([SWS_Dcm_00324]) ou, selon [SWS_Dcm_00863], que l'interface de fonction a été configurée via USE_ASYNCH_FNC/DcmDspSecurityCompareKeyFnc. L'interface est déclarée dans Dcm_Externals.h ([SWS_Dcm_91004]).

La transmission comprend le pointeur de clé à vérifier Key, l'état opérationnel actuel OpStatus (du type Dcm_OpStatusType) ainsi que le pointeur ErrorCode pour le code de réponse négatif à émettre en cas d'erreur ([SWS_Dcm_91004]). Les valeurs de retour suivantes sont spécifiées :

• E_OK : vérification de la clé réussie ([SWS_Dcm_91004]).
• DCM_E_PENDING : vérification non encore terminée ; des appels supplémentaires par le module DCM pour l'achèvement sont requis ([SWS_Dcm_91004]).
• E_NOT_OK : traitement infructueux. Le DCM envoie alors une réponse UDS négative avec le NRC défini dans ErrorCode, sans modifier le niveau de sécurité interne ni incrémenter le compteur de tentatives infructueuses (AttemptCounter) ([SWS_Dcm_01150]).
• DCM_E_COMPARE_KEY_FAILED : la clé ne correspond pas ([SWS_Dcm_91004]).

Si la comparaison de la clé échoue (DCM_E_COMPARE_KEY_FAILED), le AttemptCounter est incrémenté si DcmDspSecurityNumAttDelay est configuré ([SWS_Dcm_01397]). Si le compteur est inférieur à la valeur limite, le DCM envoie le NRC 0x35 (InvalidKey) ([SWS_Dcm_00660]). Si le nombre de tentatives infructueuses atteint ou dépasse la limite configurée DcmDspSecurityNumAttDelay, le DCM démarre le SecurityDelayTimer avec la durée DcmDspSecurityDelayTime et envoie le NRC 0x36 (exceededNumberOfAttempts) ([SWS_Dcm_01349]). Dans les deux cas, le niveau de sécurité reste inchangé.

La fonction asynchrone et non réentrante [SWS_Dcm_01152] lit depuis l'application, lors de l'initialisation du DCM, le compteur actuel de tentatives infructueuses pour un niveau de sécurité configuré. L'appel a lieu pour chaque entrée dans DcmDspSecurityRow pour laquelle le paramètre de configuration DcmDspSecurityAttemptCounterEnabled est défini sur TRUE [SWS_Dcm_01154].

La commande du déroulement est gérée via le paramètre OpStatus avec les valeurs DCM_INITIAL, DCM_PENDING ou DCM_CANCEL [SWS_Dcm_01152]. Si la fonction renvoie DCM_E_PENDING, le DCM interrompt la chaîne d'appels et la poursuit lors du cycle suivant de Dcm_MainFunction() [SWS_Dcm_01351]. Si la surveillance temporelle DcmDspSecurityMaxAttemptCounterReadoutTime configurée après le premier cycle est dépassée, le DCM abandonne l'opération encore en suspens avec DCM_CANCEL [SWS_Dcm_01352].

En cas de succès, l'interface renvoie E_OK et transmet la valeur du compteur via le paramètre de sortie AttemptCounter [SWS_Dcm_01152]. Si l'appel renvoie E_NOT_OK, le DCM initialise automatiquement le compteur à la valeur DcmDspSecurityNumAttDelay configurée pour ce niveau de sécurité [SWS_Dcm_01156].

Tant que toutes les valeurs de compteur n'ont pas été définitivement déterminées ou abandonnées, le DCM rejette chaque requête vers SecurityAccess (0x27) visant à demander un seed avec le code de réponse négatif conditionsNotCorrect (0x22) [SWS_Dcm_01354]. Après l'achèvement de la chaîne d'interrogation, le DCM vérifie les valeurs des compteurs : si au moins un compteur atteint ou dépasse la valeur de seuil DcmDspSecurityNumAttDelay, le DCM démarre le SecurityDelayTimer avec la valeur la plus élevée parmi DcmDspSecurityDelayTimeOnBoot et DcmDspSecurityDelayTime [SWS_Dcm_01355].

La fonction Xxx_SetSecurityAttemptCounter sert à définir dans l'application le compteur de tentatives pour un niveau de sécurité spécifique ([SWS_Dcm_01153]). Elle est mise à disposition via l'en-tête Dcm_Externals.h.

Appel et sémantique

L'exécution s'effectue de manière asynchrone et est spécifiée comme non réentrante (Non Reentrant) ([SWS_Dcm_01153]). L'appel pilote le déroulement via le paramètre OpStatus avec les valeurs DCM_INITIAL, DCM_PENDING ou DCM_CANCEL. La nouvelle valeur de compteur est transmise via le paramètre d'entrée AttemptCounter (uint8).

Valeurs de retour et gestion des erreurs

Le type de retour utilisé est Std_ReturnType ([SWS_Dcm_01153]) :

• E_OK : la demande s'est achevée avec succès.
• E_NOT_OK : l'exécution n'a pas réussi.
• DCM_E_PENDING : le traitement n'est pas encore terminé ; des appels supplémentaires sont nécessaires pour l'achèvement.

Si une opération asynchrone en cours est interrompue, le DCM transmet l'état DCM_CANCEL ([SWS_Dcm_01153]).

Interaction et conditions aux limites

Le module DCM appelle Xxx_SetSecurityAttemptCounter dès qu'il a modifié le compteur de tentatives, afin de notifier l'application de la mise à jour ([SWS_Dcm_01155]). Cela suppose que le paramètre de configuration DcmDspSecurityAttemptCounterEnabled pour le DcmDspSecurityRow correspondant est configuré sur TRUE ([SWS_Dcm_01155]). Comme l'interface n'est pas réentrante, l'application doit exclure toute exécution concurrente pour la même instance ([SWS_Dcm_01153]).

La fonction synchrone Xxx_ReadData demande à l'application la valeur de données actuelle d'un DID ou d'un PID lorsque le paramètre de configuration DcmDspDataUsePort est défini sur USE_DATA_SYNCH_CLIENT_SERVER [SWS_Dcm_00793]. L'interface est fournie via l'en-tête Dcm_Externals.h et possède l'ID de service 0x34 [SWS_Dcm_00793]. L'application appelée copie directement les données utiles demandées dans le tampon transmis Data [SWS_Dcm_00793].

Concernant la valeur de retour, il est défini que l'appel renvoie E_OK sans exception [SWS_Dcm_00793]. Aucun code d'erreur spécifique, réponse négative ou message DET/DEM n'est spécifié pour cette signature. Interprétation : Un échec de la mise à disposition des données n'est vraisemblablement pas prévu à ce niveau d'interface puisque, contrairement à la variante asynchrone [SWS_Dcm_91005], ni un paramètre ErrorCode pour les codes de réponse négative (NRC), ni des valeurs de retour telles que E_NOT_OK ou DCM_E_PENDING n'existent. Question Q-adcf0171ecfd37c4 (ouverte)

Concernant la concurrence et les conditions aux limites, la fonction est spécifiée comme non réentrante (Non Reentrant) et fonctionne de manière entièrement synchrone [SWS_Dcm_00793]. L'interaction avec les requêtes de diagnostic s'effectue dans plusieurs scénarios :

• Lors de la réception d'une requête OBD service $01 avec des PID de non-disponibilité, le DCM appelle les fonctions Xxx_ReadData respectivement configurées pour toutes les données du PID afin d'acquérir les valeurs de réponse [SWS_Dcm_00408].
• Lors d'une requête UDS du service 0x22 (ReadDataByIdentifier) avec des identifiants de non-disponibilité, le DCM appelle les fonctions pour toutes les données du OBDDataIdentifier [SWS_Dcm_01380] ainsi que du OBDInfoTypeDataIdentifier [SWS_Dcm_01389].
• Si un comportement asynchrone est en revanche requis, les signatures distinctes avec OpStatus interviennent conformément à [SWS_Dcm_91006] ou [SWS_Dcm_91005].

La fonction Xxx_ReadData sert à interroger de manière asynchrone les valeurs de données d'un DID ou d'un PID auprès de l'application, pour autant que le paramètre DcmDspDataUsePort soit configuré sur USE_DATA_ASYNCH_CLIENT_SERVER ([SWS_Dcm_91006]). Elle est déclarée via le fichier d'en-tête Dcm_Externals.h ([SWS_Dcm_91006]).

Lors de l'appel, le paramètre OpStatus (type Dcm_OpStatusType) contrôle la progression de l'opération en cours, tandis que via le pointeur Data (type uint8*) est transmis le tampon de sortie dans lequel les données demandées doivent être copiées ([SWS_Dcm_91006]). Comme valeurs de retour sont définies E_OK en cas d'achèvement réussi et DCM_E_PENDING si le traitement se poursuit et nécessite d'autres appels pour son achèvement ([SWS_Dcm_91006]).

Le module DCM intègre cette fonction dans les déroulements de diagnostic suivants :

• Lors de la réception d'un service OBD $01, le DCM lit les valeurs actuelles de PID (à l'exception des PID de disponibilité) via les fonctions Xxx_ReadData configurées ([SWS_Dcm_00408]).
• Pour le service UDS 0x22 (ReadDataByIdentifier), le DCM appelle la fonction pour OBDDataIdentifier ([SWS_Dcm_01380]) et OBDInfoTypeDataIdentifier ([SWS_Dcm_01389]).

Concernant l'exécution, la fonction est spécifiée comme non réentrante (Non Reentrant) ([SWS_Dcm_91006]). Contrairement à l'interface synchrone ([SWS_Dcm_00793]) ou à la variante asynchrone avec paramètre ErrorCode supplémentaire ([SWS_Dcm_91005]), cette déclinaison de fonction ne prévoit pas de retour direct d'un code de réponse négative.

La fonction Xxx_ReadData demande de manière asynchrone à l’application la valeur de données d’un DID ou d’un PID, pour autant que le paramètre de configuration DcmDspDataUsePort soit défini sur USE_DATA_ASYNCH_CLIENT_SERVER [SWS_Dcm_91005]. La déclaration de la fonction est mise à disposition via le fichier d’interface Dcm_Externals.h [SWS_Dcm_91005].

L’interface présente les caractéristiques d’appel et d’exécution suivantes :

• Sémantique et paramètres : le paramètre d’entrée OpStatus contrôle la progression de l’opération en cours [SWS_Dcm_91005]. En cas d’achèvement réussi, les données utiles demandées sont copiées dans le tampon de sortie Data et E_OK est retourné [SWS_Dcm_91005]. Si l’application requiert un temps de traitement supplémentaire, elle signale DCM_E_PENDING, à la suite de quoi des déclenchements ultérieurs sont nécessaires [SWS_Dcm_91005].
• Traitement des erreurs : si l’opération échoue et retourne E_NOT_OK, le module DCM évalue le paramètre de sortie ErrorCode et transmet une réponse de diagnostic négative avec ce code NRC [SWS_Dcm_91005].
• Concurrence : la fonction est définie comme non réentrante (Non Reentrant) [SWS_Dcm_91005]. Interprétation : les appels répétés en cas de traitement en attente devraient s’effectuer de manière séquentielle dans le cycle du traitement principal du DCM. Question Q-541226d5f242f7c2 (ouverte)
• Interaction : le module DCM appelle la fonction lors de requêtes de l’OBD Service $01 pour des PID de non-disponibilité [SWS_Dcm_00408] ainsi que lors du service UDS ReadDataByIdentifier (0x22) pour OBDDataIdentifier [SWS_Dcm_01380] et OBDInfoTypeDataIdentifier [SWS_Dcm_01389]. En comparaison avec la variante synchrone [SWS_Dcm_00793] ou des interfaces asynchrones sans paramètre NRC [SWS_Dcm_91006], cette signature permet une transmission d’erreur négative spécifique.

Utilisation

La fonction Xxx_WriteData est appelée par le Diagnostic Communication Manager (DCM) afin d'inviter l'application à écrire une valeur de données de DID (Data Identifier) ([SWS_Dcm_00794]). La déclaration est mise à disposition via l'en-tête Dcm_Externals.h. L'appel s'effectue de manière synchrone sous le Service-ID 0x51 ([SWS_Dcm_00794]).

Paramètres et valeurs de retour :

• Data (in) : pointeur vers le tampon contenant les données utiles à écrire ([SWS_Dcm_00794]).
• ErrorCode (out) : pointeur vers la variable dans laquelle le code de diagnostic négatif (NRC) doit être inscrit en cas d'échec ([SWS_Dcm_00794]).
• Valeur de retour (Std_ReturnType) : E_OK signale une écriture réussie, E_NOT_OK l'échec de l'opération ([SWS_Dcm_00794]).

Gestion des erreurs

Si la fonction renvoie E_NOT_OK, le module DCM lit le paramètre ErrorCode et émet une réponse de diagnostic négative avec ce code NRC ([SWS_Dcm_00794]).

Concurrence et restrictions

La fonction est spécifiée comme non réentrante (Non Reentrant) ([SWS_Dcm_00794]) et ne doit pas être exécutée de manière concurrente.

Interaction

Comme aucun paramètre de longueur n'existe, cette variante devrait être prévue pour des DID à longueur de données fixe. Question Q-ebc074ac1cb66aaa (ouverte) Pour les DID à longueur variable, AUTOSAR fournit la signature synchrone avec le paramètre DataLength ([SWS_Dcm_91007]). De plus, pour les déroulements de longue durée, il existe des variantes asynchrones avec OpStatus et un retour possible de DCM_E_PENDING, aussi bien avec une longueur de données fixe ([SWS_Dcm_91008]) qu'avec un paramètre de longueur variable ([SWS_Dcm_91009]).

La fonction de rappel Xxx_WriteData sert à demander à l'application d'écrire la valeur de données d'un Data Identifier (DID) [SWS_Dcm_91007]. L'interface est déclarée via l'en-tête Dcm_Externals.h et possède l'ID de service 0x52 [SWS_Dcm_91007]. L'appel s'effectue de manière synchrone et est spécifié comme non réentrant (Non Reentrant), raison pour laquelle aucun appel concurrent ne doit avoir lieu pour la même fonction [SWS_Dcm_91007].

En termes de paramètres, la fonction reçoit le tampon Data contenant les données utiles à écrire ainsi que DataLength avec l'indication de longueur en octets [SWS_Dcm_91007]. Comme valeur de retour, elle fournit le type Std_ReturnType avec E_OK en cas d'exécution réussie ou E_NOT_OK en cas d'erreur [SWS_Dcm_91007]. Si l'opération échoue et renvoie E_NOT_OK, le module DCM doit envoyer une réponse négative au testeur de diagnostic ; le code de réponse négative (NRC) correspond alors à la valeur transmise via le paramètre pointeur ErrorCode [SWS_Dcm_91007].

Dans l'ensemble du système, [SWS_Dcm_91007] représente la variante synchrone pour les DID avec indication explicite de la longueur. En complément, il existe avec [SWS_Dcm_00794] (ID de service 0x51) une variante synchrone sans le paramètre DataLength. Pour les opérations d'écriture plus longues, la norme prévoit des interfaces asynchrones : [SWS_Dcm_91008] (ID de service 0x35) sans indication de longueur ainsi que [SWS_Dcm_91009] (ID de service 0x3e) avec DataLength. Les deux fonctions asynchrones sont pilotées via OpStatus et peuvent, outre E_OK et E_NOT_OK, également renvoyer DCM_E_PENDING [SWS_Dcm_91008] [SWS_Dcm_91009].

Utilisation

La fonction Xxx_WriteData demande à l'application d'écrire la valeur de données d'un Data Identifier (DID) [SWS_Dcm_91008]. Elle est déclarée dans le fichier d'en-tête Dcm_Externals.h et possède une sémantique d'exécution asynchrone avec l'ID de service 0x35 [SWS_Dcm_91008].

Les paramètres et les valeurs de retour se structurent comme suit [SWS_Dcm_91008] :

• Data (IN) : pointeur vers le tampon contenant les données à écrire.
• OpStatus (IN) : état de l'opération en cours pour le contrôle du déroulement de l'appel asynchrone.
• ErrorCode (OUT) : pointeur vers le code d'erreur (NRC) qui est défini en cas d'erreur.
• Valeur de retour (Std_ReturnType) : E_OK confirme la réussite de l'opération d'écriture, E_NOT_OK signale un échec et DCM_E_PENDING indique que l'opération est toujours en cours et nécessite d'autres appels pour s'achever.

Gestion des erreurs et concurrence

Si l'appel renvoie la valeur E_NOT_OK, le module DCM doit envoyer une réponse négative avec la valeur de NRC transmise dans le paramètre de sortie ErrorCode [SWS_Dcm_91008]. La fonction est spécifiée comme non réentrante [SWS_Dcm_91008], de sorte que des appels simultanés ou chevauchants pour la même instance ne sont pas autorisés.

Interaction et variantes

Cette interface selon [SWS_Dcm_91008] couvre l'accès en écriture asynchrone sans paramètre de longueur distinct. AUTOSAR définit à cet effet des variantes associées dans le DCM : une signature synchrone sans indication de longueur [SWS_Dcm_00794] ainsi que des signatures avec un paramètre supplémentaire DataLength pour les déroulements synchrones [SWS_Dcm_91007] et asynchrones [SWS_Dcm_91009].

Utilisation et sémantique

La fonction Xxx_WriteData demande à l'application d'écrire la valeur de données d'un Data Identifier (DID) [SWS_Dcm_91009]. Elle est déclarée via le fichier d'en-tête Dcm_Externals.h et possède l'ID de service 0x3e [SWS_Dcm_91009]. L'exécution s'effectue de manière asynchrone (Asynchronous), pour laquelle les paramètres suivants sont transmis :

• Data (in) : pointeur vers le tampon contenant les données utiles à écrire [SWS_Dcm_91009].
• DataLength (in) : longueur des données à écrire en octets [SWS_Dcm_91009].
• OpStatus (in) : état de l'opération (Dcm_OpStatusType) pour le contrôle de la progression du traitement asynchrone [SWS_Dcm_91009].
• ErrorCode (out) : pointeur destiné à recevoir un code de réponse négative (NRC) en cas d'erreur [SWS_Dcm_91009].

Comme valeurs de retour de type Std_ReturnType, E_OK (demande d'écriture terminée avec succès), E_NOT_OK (demande ayant échoué) ainsi que DCM_E_PENDING sont définis [SWS_Dcm_91009]. L'état DCM_E_PENDING signale que l'opération n'est pas encore terminée et que d'autres appels consécutifs sont nécessaires à son achèvement [SWS_Dcm_91009]. Interprétation : le DCM devrait réappeler la fonction de façon cyclique lors du renvoi de DCM_E_PENDING avec OpStatus poursuivi jusqu'à ce qu'un résultat final soit disponible. Question Q-fdbd734dab052f5c (ouverte)

Gestion des erreurs et concurrence

Si la fonction renvoie la valeur E_NOT_OK, le code d'erreur correspondant doit être fourni via le paramètre ErrorCode ; le module DCM envoie ensuite une réponse négative avec cette valeur de NRC [SWS_Dcm_91009]. Aucun message DET ou DEM spécifique n'est défini dans le payload pour cette interface. En matière de concurrence, la fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_91009].

Interaction et variantes d'interface

La signature [SWS_Dcm_91009] couvre les accès en écriture asynchrones avec indication explicite de la longueur. D'autres variantes de Xxx_WriteData existent dans le DCM :

• Exécution synchrone sans indication de longueur : [SWS_Dcm_00794] (ID de service 0x51).
• Exécution synchrone avec indication de longueur : [SWS_Dcm_91007] (ID de service 0x52).
• Exécution asynchrone sans indication de longueur : [SWS_Dcm_91008] (ID de service 0x35).

Utilisation

Avec la fonction Xxx_ReadDataLength, le module DCM demande à l'application de déterminer et de renvoyer la longueur d'une donnée en octets [SWS_Dcm_00796]. L'interface est déclarée dans l'en-tête Dcm_Externals.h et possède l'ID de service 0x36 [SWS_Dcm_00796]. L'interrogation est exécutée de manière synchrone [SWS_Dcm_00796]. Via le paramètre de sortie DataLength de type uint16*, l'application transmet au DCM la longueur en octets des données à lire [SWS_Dcm_00796]. Aucun paramètre d'entrée ou d'entrée/sortie n'est défini [SWS_Dcm_00796]. Comme valeur de retour, la fonction renvoie toujours E_OK de type Std_ReturnType [SWS_Dcm_00796].

Concurrence et restrictions

L'interface est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_00796]. Comme la fonction fonctionne de manière synchrone et signale systématiquement E_OK selon la spécification, aucun code d'erreur spécifique ni retour d'état divergent n'est prévu pour cet appel [SWS_Dcm_00796].

Interaction

En plus de la fonction synchrone, il existe une variante asynchrone de même nom avec l'ID de service 0x4c, qui est également mise à disposition via Dcm_Externals.h [SWS_Dcm_91010]. Alors que la version synchrone [SWS_Dcm_00796] se passe d'état d'opération, son pendant asynchrone requiert le paramètre d'entrée OpStatus de type Dcm_OpStatusType [SWS_Dcm_91010]. De plus, l'interface asynchrone peut renvoyer, outre E_OK, la valeur de retour DCM_E_PENDING si la requête n'est pas encore achevée et nécessite d'autres appels pour être menée à bien [SWS_Dcm_91010].

La fonction [SWS_Dcm_91010] (ID de service 0x4c) demande à l'application de déterminer la longueur des données d'un élément de données en octets. Elle est déclarée dans l'en-tête Dcm_Externals.h et sert au Diagnostic Communication Manager (DCM) pour l'interrogation flexible de la longueur de données de diagnostic.

Utilisation et sémantique

Lors de l'appel, le module DCM transmet la progression actuelle via le paramètre d'entrée OpStatus du type Dcm_OpStatusType ([SWS_Dcm_91010]). L'application écrit le résultat de l'interrogation dans le paramètre de sortie DataLength (type uint16*). Si la longueur des données n'est pas immédiatement disponible, la fonction signale via la valeur de retour DCM_E_PENDING que le traitement se poursuit et que des appels supplémentaires sont nécessaires ([SWS_Dcm_91010]). Dès que le résultat est prêt, l'application renvoie l'achèvement avec E_OK.

Concurrence et restrictions

Conformément à la spécification, la fonction est classée comme non réentrante ([SWS_Dcm_91010]), raison pour laquelle des appels simultanés par le DCM doivent être exclus. Comme la spécification ne prévoit pas de valeurs d'erreur spécifiques hormis DCM_E_PENDING, le DCM devrait toujours considérer, lors du retour de E_OK, qu'une taille en octets valablement définie est présente. Question Q-e7ecd3a518e2cbcb (ouverte)

Interaction

L'interface asynchrone [SWS_Dcm_91010] se distingue de la variante synchrone apparentée [SWS_Dcm_00796] (ID de service 0x36). Cette dernière ne possède pas de paramètre OpStatus, est exécutée de manière synchrone et renvoie toujours immédiatement la longueur avec E_OK. [SWS_Dcm_91010] permet en revanche à l'application d'étaler des calculs coûteux en temps de manière asynchrone sur plusieurs cycles d'appel.

La fonction de callout synchrone Xxx_ConditionCheckRead est mise à disposition via le fichier d'en-tête Dcm_Externals.h et sert à demander à l'application si les conditions requises pour la lecture des données de diagnostic sont satisfaites [SWS_Dcm_00797].

L'interface ne comporte aucun paramètre d'entrée et signale le statut du contrôle par l'intermédiaire de la valeur de retour de type Std_ReturnType [SWS_Dcm_00797] :

• E_OK : le contrôle a réussi, les conditions requises pour lire les données sont remplies [SWS_Dcm_00797].
• E_NOT_OK : le contrôle a échoué, la lecture n'est pas autorisée [SWS_Dcm_00797].

Si la fonction renvoie E_NOT_OK, le module DCM envoie une réponse négative (Negative Response) avec le code d'erreur transmis par l'application via le paramètre de sortie ErrorCode (type Dcm_NegativeResponseCodeType*) [SWS_Dcm_00797].

Sur le plan de la concurrence, la fonction est spécifiée comme non réentrante (Non Reentrant) et s'exécute de manière synchrone avec le Service-ID 0x49 [SWS_Dcm_00797]. Le contrôle côté application devrait donc être évalué immédiatement sans attente bloquante, afin d'éviter tout retard pour l'appelant synchrone du DCM. Question Q-ada29c78c29d961e (ouverte)

Par opposition à cette opération synchrone, [SWS_Dcm_91011] définit une variante asynchrone sous le Service-ID 0x37. Celle-ci utilise en plus le paramètre d'entrée OpStatus (type Dcm_OpStatusType) et peut, outre E_OK et E_NOT_OK, également retourner DCM_E_PENDING si des étapes ultérieures sont nécessaires pour finaliser le contrôle [SWS_Dcm_91011].

Utilisation et sémantique

La fonction Xxx_ConditionCheckRead est fournie via le fichier d'en-tête Dcm_Externals.h et sert à demander au logiciel applicatif si les conditions pour la lecture des données de diagnostic sont remplies [SWS_Dcm_91011]. L'exécution s'effectue sous l'ID de service 0x37 de manière asynchrone [SWS_Dcm_91011]. L'état actuel de l'opération en cours est transmis via le paramètre d'entrée OpStatus (type Dcm_OpStatusType) [SWS_Dcm_91011].

Valeurs de retour et gestion des erreurs

Comme valeur de retour, la fonction fournit un statut de type Std_ReturnType [SWS_Dcm_91011] :

• E_OK : la requête a réussi et les conditions de lecture sont remplies [SWS_Dcm_91011].
• E_NOT_OK : la vérification a échoué [SWS_Dcm_91011]. Dans ce cas, l'application doit définir un code de réponse négatif (NRC) du type Dcm_NegativeResponseCodeType via le paramètre de sortie ErrorCode ; le module DCM envoie alors une réponse négative avec ce NRC [SWS_Dcm_91011].
• DCM_E_PENDING : la vérification n'est pas encore terminée, de sorte que des appels supplémentaires sont nécessaires pour l'achèvement [SWS_Dcm_91011].

Concurrence et délimitation

L'interface est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_91011]. À la différence de cette variante asynchrone, [SWS_Dcm_00797] définit sous l'ID de service 0x49 une signature synchrone sans paramètre OpStatus, qui renvoie exclusivement E_OK ou E_NOT_OK [SWS_Dcm_00797].

L'interface asynchrone Xxx_GetScalingInformation est fournie via l'en-tête Dcm_Externals.h et sert à demander des informations de mise à l'échelle d'un élément de données auprès de l'application [SWS_Dcm_91012]. Le module DCM appelle cette fonction dès qu'une requête de diagnostic pour le service UDS ReadScalingByIdentifier est reçue, et ce pour chaque donnée configurée pour le DID demandé [SWS_Dcm_00394].

Paramètres et valeurs de retour

La fonction définit les paramètres et la sémantique suivants [SWS_Dcm_91012] :

• OpStatus (in) : transmet l'état actuel de l'opération en cours.
• ScalingInfo (out) : tampon pour recevoir les informations de mise à l'échelle (scalingByte et scalingByteExtension).
• ErrorCode (out) : reçoit le code de réponse négatif si l'opération échoue.

Comme valeurs de retour, sont spécifiés E_OK en cas d'achèvement réussi, E_NOT_OK en cas d'erreur ainsi que DCM_E_PENDING si le traitement n'est pas encore terminé et nécessite d'autres appels pour l'achèvement [SWS_Dcm_91012].

Gestion des erreurs et concurrence

Si l'appel renvoie E_NOT_OK, le module DCM doit envoyer une réponse négative dont le NRC correspond à la valeur fournie via le paramètre de sortie ErrorCode [SWS_Dcm_91012]. La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_91012]. Interprétation : le fait que cette fonction asynchrone avec OpStatus ou la variante synchrone alternativement spécifiée sans OpStatus [SWS_Dcm_00798] soit appelée devrait dépendre de la configuration du DID concerné. Question Q-c4054a798f17a52c (ouverte)

La fonction Xxx_ReturnControlToECU est mise à disposition via l'en-tête Dcm_Externals.h et invite l'application à restituer le contrôle d'une commande d'entrée/sortie (IOControl) au calculateur [SWS_Dcm_01285]. L'appel s'effectue de manière synchrone et est spécifié comme non réentrant [SWS_Dcm_01285].

Paramètres et variantes

La signature de la fonction dépend de la configuration du masque de contrôle externe [SWS_Dcm_01285] :

• Si DcmDspDidControlMask est défini sur DCM_CONTROLMASK_EXTERNAL et que la taille du masque atteint jusqu'à quatre octets (DcmDspDidControlMaskSize <= 0x04), le paramètre d'entrée controlMask de type Dcm_ControlMask_{DID}Type est transmis [SWS_Dcm_01285].
• Si la taille du masque est de cinq octets ou plus (DcmDspDidControlMaskSize >= 0x05), le pointeur controlMask2 de type uint8* est utilisé à la place [SWS_Dcm_01285].
• Via le paramètre de sortie ErrorCode (type Dcm_NegativeResponseCodeType*), la fonction transmet au DCM le code de réponse négatif (NRC) spécifique en cas d'erreur [SWS_Dcm_01285].

Valeurs de retour et gestion des erreurs

La fonction renvoie l'état Std_ReturnType. En cas de restitution réussie du contrôle, l'application signale E_OK [SWS_Dcm_01285]. Si l'opération échoue, la fonction doit renvoyer E_NOT_OK ; dans ce cas, le module DCM envoie une réponse négative avec le NRC consigné dans ErrorCode au testeur de diagnostic [SWS_Dcm_01285].

Interaction et contexte d'appel

Le DCM appelle l'interface fonctionnelle configurée (paramètre DcmDspDataReturnControlToEcuFnc) lorsque DcmDspDataUsePort est configuré sur USE_DATA_SYNCH_FNC, USE_DATA_ASYNCH_FNC ou USE_DATA_ASYNCH_FNC_ERROR [SWS_Dcm_01435]. Outre les actions de diagnostic régulières, Xxx_ReturnControlToECU est notamment appelée par le DCM lorsqu'une séquence active de commande d'E/S doit être interrompue [SWS_Dcm_01435].

L'interface de fonction synchrone Xxx_ResetToDefault est mise à disposition via l'en-tête Dcm_Externals.h et sert à demander à une application de réinitialiser une commande d'E/S (IOControl) à la valeur par défaut [SWS_Dcm_01286].

Contexte d'appel et paramètres

La fonction possède l'ID de service 0x4d, fonctionne de manière synchrone et est spécifiée comme non réentrante [SWS_Dcm_01286]. En fonction de la taille configurée du masque de commande externe, l'un des deux paramètres d'entrée alternatifs est transmis :

• controlMask (type Dcm_ControlMask_{DID}Type) est utilisé lorsque DcmDspDataUsePort est configuré sur USE_DATA_SYNCH_FNC, que DcmDspDidControlMask est positionné sur DCM_CONTROLMASK_EXTERNAL et que DcmDspDidControlMaskSize est inférieur ou égal à 0x04 [SWS_Dcm_01286].
• controlMask2 (type uint8*) est utilisé lorsque, sous des conditions identiques, DcmDspDidControlMaskSize est configuré comme étant supérieur ou égal à 0x05 [SWS_Dcm_01286].

Valeurs de retour et gestion des erreurs

Si la réinitialisation a pu être effectuée avec succès, la fonction renvoie E_OK [SWS_Dcm_01286]. Si l'opération échoue, E_NOT_OK doit être retourné. Dans ce cas, l'application affecte au paramètre de sortie ErrorCode (type Dcm_NegativeResponseCodeType*) le code de réponse négatif (NRC) correspondant, que le module DCM transmet au testeur en tant que retour négatif [SWS_Dcm_01286].

Interaction et délimitation

Si le système est conçu pour des traitements d'interface asynchrones via USE_DATA_ASYNCH_FNC ou USE_DATA_ASYNCH_FNC_ERROR, la variante asynchrone avec le paramètre supplémentaire OpStatus et l'ID de service 0x3c est utilisée à la place de cette fonction synchrone [SWS_Dcm_01314].

La fonction asynchrone [SWS_Dcm_01314] demande à l'application de réinitialiser une commande d'entrée/sortie (IOControl) à sa valeur par défaut. Elle est déclarée dans Dcm_Externals.h et possède l'ID de service 0x3c. La progression de l'opération est gérée via le paramètre OpStatus. Si le traitement n'est pas encore terminé, la fonction renvoie DCM_E_PENDING, tandis qu'un achèvement réussi est confirmé par E_OK.

Selon la configuration et la taille du masque (DcmDspDidControlMaskSize à 4 octets ou à partir de 5 octets), controlMask ou controlMask2 est en outre transmis en cas de masquage externe [SWS_Dcm_01314]. Si la réinitialisation échoue, la fonction renvoie E_NOT_OK. Dans ce cas, un code de réponse négatif (NRC) doit être transmis via le paramètre de sortie ErrorCode, que le module DCM envoie au testeur en tant que réponse négative [SWS_Dcm_01314].

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_01314]. Elle est utilisée lorsque DcmDspDataUsePort est défini sur USE_DATA_ASYNCH_FNC ou USE_DATA_ASYNCH_FNC_ERROR. Pour les configurations d'interface synchrones (USE_DATA_SYNCH_FNC), il existe en alternative la variante synchrone sans OpStatus [SWS_Dcm_01286].

Utilisation

La fonction synchrone Xxx_FreezeCurrentState (référencée dans le catalogue d'éléments sous Xxx_FreezeCurrentStateManager) sert à demander à une application de figer l'état actuel d'une commande d'entrée ou de sortie (IOControl) [SWS_Dcm_01290]. La fonction est disponible via le fichier d'en-tête Dcm_Externals.h et possède l'ID de service 0x4a AUTOSAR_SWS_DiagnosticCommunicationManager p. 279. (Interpretation : le préfixe Xxx devrait ici faire office d'espace réservé pour le module applicatif respectif.) Question Q-f8c864cda732acc2 (ouverte)

Les paramètres d'interface dépendent de la configuration du masque de contrôle externe (DcmDspDidControlMask sur DCM_CONTROLMASK_EXTERNAL) [SWS_Dcm_01290] :

• controlMask (entrée, type Dcm_ControlMask_{DID}Type) : est transmis lorsque la taille de masque DcmDspDidControlMaskSize est configurée comme inférieure ou égale à 4 octets (<= 0x04).
• controlMask2 (entrée, type uint8*) : est utilisé à la place lorsque la taille de masque comprend au moins 5 octets (=> 0x05).
• ErrorCode (sortie, type Dcm_NegativeResponseCodeType*) : pointeur destiné à recevoir un code de réponse négatif en cas d'erreurs.

Gestion des erreurs et valeurs de retour

La fonction fournit comme Std_ReturnType soit E_OK en cas d'exécution réussie, soit E_NOT_OK si la demande a échoué [SWS_Dcm_01290]. Si une erreur survient et que E_NOT_OK est renvoyé, l'application doit consigner un code de réponse négatif (NRC) spécifique dans le paramètre ErrorCode ; le module DCM envoie ensuite une réponse de diagnostic négative avec ce code NRC AUTOSAR_SWS_DiagnosticCommunicationManager p. 279.

Concurrence et restrictions

L'opération est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_01290]. Les appelants doivent s'assurer que les appels pour la même instance sont traités de manière synchrone et sans chevauchement simultané.

Utilisation et contexte d'appel

La fonction asynchrone Xxx_FreezeCurrentState est appelée par le module DCM afin de demander au logiciel applicatif le gel de l'état actuel d'une commande d'entrée/sortie (IOControl) [SWS_Dcm_01315]. La déclaration est mise à disposition via l'en-tête Dcm_Externals.h [SWS_Dcm_01315].

Paramètres et masques de contrôle

L'appel a lieu avec les paramètres suivants [SWS_Dcm_01315] :

• OpStatus : transmet l'état actuel de l'opération asynchrone (Dcm_OpStatusType).
• controlMask ou controlMask2 : lorsque le masque de commande est configuré de manière externe (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL) et que l'interface de fonction asynchrone est utilisée, le DCM transmet, en fonction de DcmDspDidControlMaskSize, le paramètre controlMask (de type Dcm_ControlMask_{DID}Type) jusqu'à 4 octets et, à partir de 5 octets, le pointeur controlMask2 (uint8*).
• ErrorCode : pointeur vers Dcm_NegativeResponseCodeType pour le renvoi d'un code d'erreur.

Valeurs de retour et gestion des erreurs

La fonction renvoie un statut de type Std_ReturnType [SWS_Dcm_01315] :

• E_OK : le figeage de l'état s'est achevé avec succès.
• DCM_E_PENDING : la requête est toujours en cours de traitement et requiert des transmissions ultérieures.
• E_NOT_OK : l'opération a échoué. Dans ce cas, le DCM envoie une réponse de diagnostic négative avec la valeur de NRC définie via ErrorCode.

concurrence

L'interface est définie comme non réentrante (Non Reentrant) et nécessite donc un traitement synchronisé par instance de commande [SWS_Dcm_01315].

La fonction synchrone Xxx_ShortTermAdjustment demande à l'application d'adapter temporairement un signal d'E/S donné [SWS_Dcm_00802]. Elle est mise à disposition via l'en-tête Dcm_Externals.h et possède l'ID de service 0x50 [SWS_Dcm_00802].

Via le pointeur ControlStateInfo, la fonction reçoit les informations d'état de commande issues du paramètre ControlOptionRecord de la requête de diagnostic InputOutputControlByIdentifier [SWS_Dcm_00802]. Si un masque de commande externe est configuré (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL), soit controlMask (jusqu'à 4 octets) de type Dcm_ControlMask_{DID}Type, soit controlMask2 (à partir de 5 octets) sous forme de uint8* est transmis en plus en fonction de DcmDspDidControlMaskSize [SWS_Dcm_00802].

Comme valeur de retour, l'opération renvoie Std_ReturnType [SWS_Dcm_00802] :

• E_OK : l'adaptation du signal d'E/S a été exécutée avec succès [SWS_Dcm_00802].
• E_NOT_OK : l'adaptation a échoué [SWS_Dcm_00802]. Dans ce cas, l'application doit définir un code de réponse négative spécifique (Dcm_NegativeResponseCodeType) via le paramètre de sortie ErrorCode, que le module DCM renvoie au testeur dans la réponse de diagnostic négative [SWS_Dcm_00802].

La fonction est non réentrante (Non Reentrant) et est appelée de manière synchrone [SWS_Dcm_00802]. Cette variante synchrone est utilisée lorsque l'élément de données est configuré pour des appels de fonction synchrones (DcmDspDataUsePort == USE_DATA_SYNCH_FNC) [SWS_Dcm_00802]. Pour les ports configurés de façon asynchrone (USE_DATA_ASYNCH_FNC ou USE_DATA_ASYNCH_FNC_ERROR), il existe en revanche la variante asynchrone avec l'ID de service 0x55 et un jeu de paramètres étendu incluant OpStatus et DataLength [SWS_Dcm_01316].

Utilisation et contexte d'appel

La fonction [SWS_Dcm_01316] est appelée par le Diagnostic Communication Manager (DCM) et fournie via Dcm_Externals.h. Elle demande de manière asynchrone à l'application d'adapter un signal d'E/S dans le cadre du service de diagnostic InputOutputControlByIdentifier. Les données de commande sont transmises via le pointeur ControlStateInfo (issu du paramètre ControlOptionRecord), complétées par la longueur en octets DataLength. Le déroulement est géré via OpStatus : tant que l'adaptation se poursuit, l'application renvoie DCM_E_PENDING ; après un achèvement réussi, elle signale E_OK.

Variantes et paramètres de masque

En cas de configuration externe du masque de contrôle (DCM_CONTROLMASK_EXTERNAL), des paramètres supplémentaires sont transmis [SWS_Dcm_01316] :

• Si la taille du masque est inférieure ou égale à 4 octets, controlMask du type Dcm_ControlMask_{DID}Type est transmis.
• Si la taille du masque est d'au moins 5 octets, controlMask2 est transmis à la place en tant que pointeur vers uint8.

Gestion des erreurs et concurrence

Si la commande du signal échoue, la fonction renvoie E_NOT_OK et définit via le pointeur ErrorCode le code de réponse négatif (NRC), que le DCM transmet dans la réponse négative [SWS_Dcm_01316]. La fonction est spécifiée comme non réentrante.

Interaction et délimitation

L'interface est utilisée lorsque le port de données DID est configuré sur USE_DATA_ASYNCH_FNC ou USE_DATA_ASYNCH_FNC_ERROR et que le type de données est configuré sur UINT8_DYN [SWS_Dcm_01316]. Elle se distingue de la variante synchrone [SWS_Dcm_00802], qui n'utilise ni OpStatus ni DataLength et est destinée aux ports synchrones avec des types de données statiques.

La fonction Xxx_IsDidAvailable sert à vérifier de manière asynchrone si un identifiant de diagnostic (DID) demandé est disponible au sein d'une plage de DID définie [SWS_Dcm_00803]. Elle est mise à disposition via l'en-tête Dcm_Externals.h et possède l'ID de service 0x53 [SWS_Dcm_00803].

Utilisation et paramètres

L'appel a lieu avec les paramètres suivants [SWS_Dcm_00803] :

• DID (In) : la valeur d'identifiant du DID à interroger [SWS_Dcm_00803].
• OpStatus (In) : l'état actuel de l'opération pour piloter le déroulement asynchrone [SWS_Dcm_00803].
• supported (Out) : indique si le DID est disponible dans la plage ; DCM_DID_SUPPORTED signifie une prise en charge, tandis que DCM_DID_NOT_SUPPORTED indique une non-prise en charge [SWS_Dcm_00803].

Sémantique asynchrone et valeurs de retour

Comme la fonction est exécutée de manière asynchrone, la détermination requiert éventuellement plusieurs étapes d'appel [SWS_Dcm_00803]. La valeur de retour DCM_E_PENDING signale que la requête n'est pas encore terminée et que d'autres appels sont nécessaires pour la finaliser [SWS_Dcm_00803]. La valeur de retour E_OK est rapportée lorsque la vérification est achevée [SWS_Dcm_00803] (interprétation : E_OK termine vraisemblablement l'interrogation, après quoi le paramètre supported contient le résultat valide). Question Q-22c62d306a7ac4f1 (ouverte)

Concurrence et restrictions

L'interface est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_00803]. Des appels parallèles pour le même DID ou d'autres DID au sein d'une même instance sont donc non autorisés.

Utilisation et interface de paramètres

La fonction Xxx_ReadDidData (ID de service 0x40) est disponible via Dcm_Externals.h et demande à l'application les valeurs de données d'un identificateur de diagnostic (DID) [SWS_Dcm_00804]. La transmission et le retour s'effectuent via les paramètres suivants :

• DID : identifiant du Data Identifier demandé [SWS_Dcm_00804].
• Data : pointeur vers le tampon dans lequel les données utiles lues doivent être copiées [SWS_Dcm_00804].
• OpStatus : statut de progression ou d'opération de la demande actuelle [SWS_Dcm_00804].
• DataLength : longueur des données à lire [SWS_Dcm_00804].
• ErrorCode : paramètre de sortie destiné à recevoir un code de réponse négative (NRC) [SWS_Dcm_00804].

Sémantique asynchrone et valeurs de retour

La fonction est définie comme asynchrone (Asynchronous) et renvoie un état de type Std_ReturnType [SWS_Dcm_00804] :

• E_OK : la lecture des données a réussi [SWS_Dcm_00804].
• DCM_E_PENDING : la demande n'est pas encore terminée ; des appels supplémentaires sont requis pour l'achèvement [SWS_Dcm_00804].
• E_NOT_OK : l'opération a échoué [SWS_Dcm_00804].

Gestion des erreurs et concurrence

Si l'application renvoie la valeur de retour E_NOT_OK pour Xxx_ReadDidData, le module DCM envoie une réponse négative avec le code NRC défini via le paramètre ErrorCode au testeur de diagnostic [SWS_Dcm_00804]. La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Dcm_00804]. Interprétation : en raison du traitement asynchrone avec DCM_E_PENDING, l'appel devrait typiquement avoir lieu dans le contexte de tâche cyclique du DCM. Question Q-5e41e9fb7dc261b9 (ouverte)

La fonction Xxx_WriteDidData est appelée par le module DCM afin d'inviter l'application à écrire la valeur de données d'un DID [SWS_Dcm_00805]. La déclaration est disponible via l'en-tête Dcm_Externals.h [SWS_Dcm_00805].

Appel et sémantique

L'appel s'effectue de manière asynchrone et est défini comme non réentrant (Non Reentrant) [SWS_Dcm_00805]. Les paramètres suivants sont transmis lors de l'appel [SWS_Dcm_00805] :

• DID : identifiant de l'identificateur de données à écrire.
• Data : pointeur vers le tampon contenant les données à écrire.
• OpStatus : état de l'opération actuelle.
• DataLength : longueur des données à écrire en octets.
• ErrorCode : paramètre de sortie pour le code de réponse négative (NRC).

Valeurs de retour et gestion des erreurs

Comme valeur de retour, la fonction fournit Std_ReturnType avec les significations suivantes [SWS_Dcm_00805] :

• E_OK : l'ordre d'écriture a été exécuté avec succès.
• DCM_E_PENDING : l'opération n'est pas encore terminée ; des appels supplémentaires sont nécessaires pour l'achèvement.
• E_NOT_OK : l'opération a échoué. Dans ce cas, le module DCM envoie une réponse négative avec la valeur de NRC transmise dans le paramètre de sortie ErrorCode.

La fonction Xxx_ReadDidRangeDataLength sert à inviter le logiciel applicatif à renvoyer la longueur des données pour une plage de DID (DID Range) [SWS_Dcm_01271]. Elle fait partie intégrante du module AUTOSAR Dcm, possède l'ID de service 0x5e et est mise à disposition via le fichier d'en-tête Dcm_Externals.h [SWS_Dcm_01271].

L'appel s'effectue avec une sémantique asynchrone (Asynchronous) via les paramètres d'interface suivants [SWS_Dcm_01271] :

• DID (IN, uint16) : caractérise l'identifiant de données concret (Data ID value) de la plage de DID demandée [SWS_Dcm_01271].
• OpStatus (IN, Dcm_OpStatusType) : indique l'état de traitement actuel de l'opération en cours [SWS_Dcm_01271].
• DataLength (OUT, uint16*) : pointeur vers la longueur des données devant être lues ou écrites [SWS_Dcm_01271].

La valeur de retour de type Std_ReturnType signale le résultat de l'interrogation de longueur [SWS_Dcm_01271] :

• E_OK : la requête a réussi et la longueur déterminée est disponible [SWS_Dcm_01271].
• E_NOT_OK : la requête a échoué [SWS_Dcm_01271].
• DCM_E_PENDING : l'exécution n'est pas encore terminée et requiert d'autres appels ultérieurs pour son achèvement [SWS_Dcm_01271].

Concernant la concurrence, l'interface est définie comme non réentrante (Non Reentrant) [SWS_Dcm_01271].

L'interface asynchrone Xxx_GetInfotypeValueData est appelée par le module DCM dès qu'une requête de diagnostic pour l'OBD Service $09 est reçue et que l'InfoType demandé n'est pas un InfoType de disponibilité (« availability InfoType ») [SWS_Dcm_00423]. Pour fournir les données, le DCM appelle toutes les fonctions configurées pour cet InfoType et rassemble les valeurs sous forme de réponse au Service $09 [SWS_Dcm_00423]. La déclaration est disponible via Dcm_Externals.h [SWS_Dcm_91014].

La transmission et le retour des données s'effectuent via des paramètres de tampon et d'état définis [SWS_Dcm_91014] :

• OpStatus (in) : indique l'état d'avancement actuel de l'opération en cours.
• DataValueBuffer (out) : tampon destiné à recevoir les données utiles spécifiques de l'InfoType.
• DataValueBufferSize (inout) : contient lors de l'appel la taille maximale inscriptible du tampon en octets et est renseigné par la fonction appelée avec le nombre effectif d'octets de données écrits.

En tant que fonction asynchrone, elle renvoie E_OK en cas d'achèvement réussi, E_NOT_OK en cas d'erreurs ou DCM_E_PENDING si l'opération n'est pas encore terminée et nécessite d'autres appels pour son achèvement [SWS_Dcm_91014]. Comme la fonction est spécifiée comme non réentrante (Non Reentrant), aucun appel concurrent ne doit avoir lieu pour la même fonction [SWS_Dcm_91014].

La fonction Xxx_Start est déclarée via le fichier d'en-tête Dcm_Externals.h et demande au logiciel d'application de démarrer l'exécution d'une routine de diagnostic [SWS_Dcm_01203]. Le module DCM appelle cette fonction dès qu'une requête de service UDS pour RoutineControl (0x31) avec la sous-fonction startRoutine a été reçue et vérifiée avec succès [SWS_Dcm_00400], ou lorsqu'une requête RoutineControl avec un OBDTestId de non-disponibilité arrive [SWS_Dcm_01392].

L'interface prend en charge des formats de données fixes ainsi que variables et fonctionne de manière asynchrone [SWS_Dcm_01203] :

• Paramètres d'entrée : signaux d'entrée fixes dataIn_1 à dataIn_n ou données variables via le tableau d'octets dataInVar, ainsi que l'état d'opération OpStatus [SWS_Dcm_01203].
• Paramètres de sortie : signaux de sortie fixes dataOut_1 à dataOut_n ou données de sortie variables dataOutVar, ainsi que le code d'erreur ErrorCode pour les messages de réponse négative [SWS_Dcm_01203].
• Paramètres de longueur : le paramètre d'entrée-sortie currentDataLength transporte, en cas de longueur de données variable, le nombre d'octets utiles dans dataInVar ou dataOutVar [SWS_Dcm_01203].
• Valeurs de retour : E_OK confirme le démarrage réussi, E_NOT_OK signale un échec, DCM_E_PENDING signale des étapes de traitement encore en cours et DCM_E_FORCE_RCRRP demande l'envoi anticipé d'un retour Pending (NRC 0x78) [SWS_Dcm_01203].

Concernant la concurrence, Xxx_Start est défini comme non réentrant (Non Reentrant) [SWS_Dcm_01203]. Lors de déroulements asynchrones avec la valeur de retour DCM_E_PENDING, le module DCM rappelle la fonction de façon cyclique avec OpStatus poursuivi jusqu'à ce que l'opération soit terminée [SWS_Dcm_01203].

Si l'opération se termine avec succès par E_OK, le module DCM renvoie une réponse UDS positive avec les données mises à disposition via dataOut en tant que routineStatusRecord [SWS_Dcm_00401]. Si l'exécution échoue avec E_NOT_OK, le DCM transmet une réponse négative avec le NRC spécifié dans le paramètre ErrorCode [SWS_Dcm_01203]. Dans le contexte de routines OBD, une valeur de retour différente de E_OK entraîne l'envoi du NRC 0x22 [SWS_Dcm_01394].

Utilisation

La fonction Xxx_StartConfirmation indique de manière contraignante, conformément à [SWS_Dcm_91016], la transmission d'une réponse à une requête StartRoutine précédente. L'interface est déclarée dans le fichier d'en-tête Dcm_Externals.h et possède une sémantique d'exécution synchrone ([SWS_Dcm_91016]). Comme unique paramètre d'entrée, ConfirmationStatus du type Dcm_ConfirmationStatusType est transmis, qui décrit le statut de confirmation de la transmission de la routine. Selon la spécification, il n'existe pas de paramètres d'entrée et de sortie supplémentaires ([SWS_Dcm_91016]).

Gestion des erreurs et valeurs de retour

Comme valeur de retour, la fonction fournit une valeur d'état du type Std_ReturnType ([SWS_Dcm_91016]). La valeur E_OK confirme ici la bonne exécution de la requête, tandis que E_NOT_OK signale un traitement non réussi. Aucun code d'erreur spécifique ou message explicite destiné au Development Error Tracer (DET) ou au Diagnostic Event Manager (DEM) n'est défini dans la charge utile pour cette fonction.

Concurrence et restrictions

En ce qui concerne la concurrence, Xxx_StartConfirmation est classé comme non réentrant (Non Reentrant) ([SWS_Dcm_91016]). Cela exige de l'appelant d'éviter strictement toute exécution concurrente ou chevauchante. Interprétation : la fonction devrait être appelée par le DCM afin d'informer l'implémentation de la routine côté application de l'achèvement de l'opération d'envoi. Question Q-be2dafd63bf2a9a5 (ouverte)

Utilisation

La fonction [SWS_Dcm_01204] est appelée par le DCM afin d'arrêter l'exécution d'une routine de diagnostic en cours dans l'application. L'appel intervient dans le cadre du service UDS RoutineControl (0x31) avec la sous-fonction stopRoutine, dès que les vérifications préalables requises ont abouti avec succès [SWS_Dcm_00402]. L'interface possède l'ID de service 0x5c et est déclarée via le fichier d'en-tête Dcm_Externals.h [SWS_Dcm_01204].

Paramètres et valeurs de retour

En fonction de la configuration de la routine, le DCM transmet des données d'entrée fixes ou variables (dataIn_1 à dataIn_n ou dataInVar) et des références de tampon pour les données de sortie (dataOut_1 à dataOut_n ou dataOutVar) [SWS_Dcm_01204], [SWS_Dcm_00402]. En cas de longueur de données variable, currentDataLength contient le nombre d'octets des données d'entrée ou de sortie [SWS_Dcm_01204]. Les valeurs de retour suivantes sont définies pour Std_ReturnType :

• E_OK : routine terminée avec succès ; le DCM transmet une réponse positive UDS avec les données de sortie générées sous forme de routineStatusRecord [SWS_Dcm_01204], [SWS_Dcm_00403].
• E_NOT_OK : échec de l'interruption de la routine ; le DCM envoie une réponse négative UDS avec le NRC consigné dans ErrorCode [SWS_Dcm_01204].
• DCM_E_PENDING : opération toujours en cours de traitement ; le DCM appelle à nouveau la fonction pour l'achèvement [SWS_Dcm_01204].
• DCM_E_FORCE_RCRRP : l'application invite le DCM à transmettre une réponse en attente (NRC 0x78) [SWS_Dcm_01204].

Concurrence et restrictions

L'opération est spécifiée comme asynchrone et non réentrante (Non Reentrant) [SWS_Dcm_01204]. Si une erreur survient lors de l'exécution, l'application doit renseigner le paramètre ErrorCode avec le Dcm_NegativeResponseCodeType approprié et renvoyer E_NOT_OK [SWS_Dcm_01204].

La fonction synchrone Xxx_StopConfirmation sert à indiquer la transmission d'une réponse à une requête StopRoutine précédente [SWS_Dcm_91017]. Lors de l'appel, le système transmet via le paramètre d'entrée ConfirmationStatus du type Dcm_ConfirmationStatusType le statut de confirmation concret de l'arrêt de la routine [SWS_Dcm_91017]. Comme valeur de retour, l'interface fournit une valeur du type Std_ReturnType : ici, E_OK indique que la requête a été traitée avec succès, tandis que E_NOT_OK signale une requête infructueuse [SWS_Dcm_91017].

En matière de concurrence et de conditions d'appel, l'interface est spécifiée comme non réentrante (Non Reentrant) et possède l'ID de service 0x69 [SWS_Dcm_91017]. La déclaration est mise à disposition via le fichier d'en-tête Dcm_Externals.h [SWS_Dcm_91017]. Interprétation : en raison de sa fourniture via Dcm_Externals.h et du préfixe adaptable Xxx_, la fonction devrait être appelée par le module DCM et implémentée par un composant logiciel spécifique à l'application ou par le gestionnaire de routine responsable. Question Q-743e69ff8cf92321 (ouverte)

Aucun code d'erreur spécifique ou notification destinée à la gestion des erreurs de développement (DET) ou au Diagnostic Event Manager (DEM) n'est indiqué dans les exigences. Le comportement en cas d'erreur se limite formellement, à ce niveau d'interface, au renvoi de la valeur d'erreur E_NOT_OK lorsque le traitement n'a pas pu s'achever avec succès [SWS_Dcm_91017].

La fonction [SWS_Dcm_91013] est appelée par le module DCM afin d'interroger auprès de l'application le résultat d'une exécution de routine. Cela se produit dans le cadre du service UDS RoutineControl (0x31) avec la sous-fonction requestRoutineResults, dès que toutes les vérifications côté entrée ont été validées avec succès [SWS_Dcm_00404]. L'interface est disponible via Dcm_Externals.h, fonctionne de manière asynchrone et est spécifiée comme non réentrante [SWS_Dcm_91013].

Via le paramètre OpStatus, le module DCM pilote le déroulement de l'opération. La fonction reçoit des données d'entrée fixes (dataIn_1 à dataIn_n) ou des données variables (dataInVar) dérivées du routineControlOptionRecord [SWS_Dcm_00404]. Via des paramètres de sortie fixes (dataOut_1 à dataOut_n) ou des tampons de sortie variables (dataOutVar et variableDataLength), l'application transmet les données de résultat au DCM [SWS_Dcm_91013].

Si l'interrogation s'achève avec succès avec E_OK, le module DCM rassemble les données de sortie à l'aide du paramètre de configuration DcmDspRequestRoutineResultsOut en un routineStatusRecord et transmet une réponse positive [SWS_Dcm_00405]. Si l'opération se poursuit, l'application peut renvoyer DCM_E_PENDING pour des appels ultérieurs ou DCM_E_FORCE_RCRRP pour l'envoi d'une réponse provisoire (NRC 0x78) [SWS_Dcm_91013].

En cas d'erreur, la fonction renvoie E_NOT_OK et positionne ErrorCode sur la valeur de NRC correspondante, après quoi le module DCM transmet une réponse négative appropriée [SWS_Dcm_91013]. Étant donné que la fonction n'est pas réentrante, elle ne doit pas être appelée en parallèle pour la même routine [SWS_Dcm_91013].

Utilisation et sémantique

La fonction Xxx_RequestResultsConfirmation sert à la confirmation d'une réponse de diagnostic transmise suite à une requête RequestRoutineResults [SWS_Dcm_91018]. Elle est déclarée dans le fichier d'en-tête Dcm_Externals.h et possède l'ID de service 0x70 [SWS_Dcm_91018]. Via le paramètre d'entrée ConfirmationStatus du type Dcm_ConfirmationStatusType, l'implémentation reçoit l'information indiquant avec quel statut la transmission des résultats de la routine s'est achevée [SWS_Dcm_91018]. L'appel est exécuté de manière synchrone et renvoie un Std_ReturnType, E_OK indiquant un traitement réussi et E_NOT_OK signalant un échec [SWS_Dcm_91018].

Concurrence et restrictions

Conformément à la spécification, la fonction est classée comme non réentrante (Non Reentrant) [SWS_Dcm_91018]. Par conséquent, des appels simultanés pour la même instance ne doivent pas avoir lieu. Interprétation : l'appel par le module DCM s'effectue séquentiellement dans le contexte de la confirmation de réponse, raison pour laquelle la fonction devrait être exécutée sans opérations bloquantes. Question Q-935a06744e7b9af7 (ouverte)

Traitement des erreurs et interaction

Le traitement des erreurs se limite à la valeur de retour E_NOT_OK, étant donné qu'aucune erreur de développement spécifique (DET) ou erreur de production (DEM) n'est spécifiée pour cet appel [SWS_Dcm_91018]. Interprétation : la fonction sert de point de terminaison de confirmation (rappel) spécifique à l'application pour le DCM afin de synchroniser, au niveau de l'application, l'achèvement de la commande de diagnostic après l'envoi des résultats de la routine. Question Q-d3dd0142a30e1363 (ouverte)

La fonction Xxx_RequestControl sert à exécuter une fonction de commande spécifique au TID et est généralement employée pour l'implémentation de l'OBD Service $08 ([SWS_Dcm_01338]). Le module DCM appelle la fonction configurée de manière synchrone dès qu'une requête OBD Service $08 est reçue dont l'identifiant de test (TID) ne constitue pas un TID de disponibilité (« availability TID ») ([SWS_Dcm_00419]). La déclaration de l'interface est mise à disposition via le fichier d'en-tête Dcm_Externals.h ([SWS_Dcm_01338]).

Paramètres et gestion du tampon

• InBuffer : pointeur vers les données utiles de la requête OBD reçue. Le nombre d'octets de ces données d'entrée doit correspondre exactement à la taille configurée dans le module DCM ([SWS_Dcm_00419], [SWS_Dcm_01338]).
• OutBuffer : pointeur vers le tampon de sortie dans lequel la fonction de commande appelée dépose ses résultats. La taille du tampon est fixe et est tirée de la configuration du module DCM ([SWS_Dcm_00419], [SWS_Dcm_01338]).

Valeurs de retour et gestion des erreurs

La fonction renvoie Std_ReturnType comme valeur d'état : la valeur E_OK signale un traitement réussi, tandis que E_NOT_OK indique un état d'erreur ([SWS_Dcm_01338]). Si Xxx_RequestControl renvoie un résultat différent de E_OK, le module DCM réagit vis-à-vis du testeur de diagnostic avec le code de réponse négative NRC 0x22 (Conditions Not Correct) ([SWS_Dcm_01192]).

Concurrence et restrictions

La fonction est spécifiée comme non réentrante (Non Reentrant) et possède l'identifiant de service 0x63 ([SWS_Dcm_01338]).

La fonction de rappel Xxx_StartProtocol est fournie via le fichier d'en-tête Dcm_Externals.h et permet à l'application, lors de la première requête d'un protocole de diagnostic, de vérifier les conditions d'environnement actuelles et d'autoriser ou de rejeter la poursuite du traitement du protocole [SWS_Dcm_01339].

Contexte d'appel et paramètres

L'appel est effectué par le sous-module DSL du DCM de manière synchrone et non réentrante pour toutes les fonctions configurées [SWS_Dcm_00036], [SWS_Dcm_01339]. Les paramètres d'entrée suivants sont transmis à la fonction [SWS_Dcm_01339] :

• ProtocolType : type du protocole de diagnostic à démarrer,
• TesterSourceAddress : adresse source du testeur demandeur,
• ConnectionId : identifiant unique de la connexion.

Valeurs de retour et gestion des erreurs

Comme valeur de retour, la fonction fournit Std_ReturnType avec E_OK en cas d'autorisation réussie, E_NOT_OK en cas de vérification infructueuse ou E_PROTOCOL_NOT_ALLOWED si le protocole n'est pas autorisé [SWS_Dcm_01339]. Si au moins une fonction Xxx_StartProtocol configurée ne renvoie pas E_OK, le DCM interrompt le démarrage du protocole et répond avec NRC 0x22 [SWS_Dcm_00674].

Initialisation après autorisation réussie

Ce n'est que lorsque tous les rappels Xxx_StartProtocol configurés ont renvoyé E_OK que le DCM exécute les étapes d'initialisation suivantes :

• Chargement des paramètres de temporisation standard à partir de la configuration de session par défaut [SWS_Dcm_00144],
• Activation de la table des services [SWS_Dcm_00145],
• Réinitialisation de l'état de sécurité (Security State) [SWS_Dcm_00146],
• Réinitialisation de l'état de session vers la session de diagnostic standard ainsi qu'exécution du changement de mode via SchM_Switch_<bsnp>_DcmDiagnosticSessionControl vers RTE_MODE_DcmDiagnosticSessionControl_DEFAULT_SESSION [SWS_Dcm_00147].

La fonction de rappel synchrone Xxx_StopProtocol informe l'application de la fin d'un protocole de diagnostic ([SWS_Dcm_01340]). Elle est déclarée via le fichier d'en-tête Dcm_Externals.h et est spécifiée comme non réentrante (Non Reentrant) ([SWS_Dcm_01340]).

L'appel de toutes les fonctions Xxx_StopProtocol configurées (configurées via le paramètre DcmDslCallbackDCMRequestService) est déclenché par le sous-module DSL dans les scénarios de préemption suivants :

• Une requête de diagnostic en cours est évincée par une requête plus prioritaire d'un autre protocole ([SWS_Dcm_00459]).
• Une requête de priorité inférieure ou égale évince un protocole plus prioritaire, pour autant que celui-ci se trouve dans la session par défaut et qu'aucune requête active ne soit en phase d'exécution ([SWS_Dcm_00625]).

Lors de l'appel, le type de protocole (ProtocolType), l'adresse source du testeur (TesterSourceAddress) ainsi que l'identifiant de connexion (ConnectionId) sont transmis ([SWS_Dcm_01340]). Comme valeur de retour, la fonction fournit E_OK en cas d'exécution réussie ou E_NOT_OK ([SWS_Dcm_01340]). Si la fonction ne renvoie pas E_OK, le DCM répond avec le code de réponse négatif NRC 0x22 ([SWS_Dcm_01190]).

La fonction synchrone et non réentrante Xxx_Indication est déclarée via l'en-tête Dcm_Externals.h [SWS_Dcm_01341]. Elle signale à l'application l'exécution imminente d'un service de diagnostic et lui permet de rejeter l'exécution de la requête de service [SWS_Dcm_01341]. L'appel est effectué de manière synchrone par le sous-module DSD sur tous les ports ServiceRequestIndication configurés lorsque les conteneurs de configuration DcmDsdServiceRequestManufacturerNotification [SWS_Dcm_00218] ou DcmDsdServiceRequestSupplierNotification [SWS_Dcm_00516] sont présents.

Sont transmis comme paramètres d'entrée l'identifiant de service (SID), les données de requête sans SID (RequestData, DataSize), le type d'adressage (ReqType), l'ID de connexion (ConnectionId), le type de protocole (ProtocolType) et l'adresse source du testeur (TesterSourceAddress) [SWS_Dcm_01341].

Via la valeur de retour de type Std_ReturnType, l'application pilote la réaction du sous-module DSD [SWS_Dcm_01341] :

• E_OK : la requête a été acceptée avec succès et continue d'être traitée normalement [SWS_Dcm_01341].
• E_REQUEST_NOT_ACCEPTED : la requête n'est pas acceptée. Si au moins une fonction d'indication appelée renvoie E_REQUEST_NOT_ACCEPTED, le sous-module DSD supprime toute réponse vers le testeur [SWS_Dcm_00462], [SWS_Dcm_00517].
• E_NOT_OK : la requête n’a pas abouti. Dans ce cas, l’application écrit un code de réponse négatif dans le paramètre de sortie ErrorCode [SWS_Dcm_01341]. Pour autant qu’aucun appel ne retourne E_REQUEST_NOT_ACCEPTED, le sous-module DSD transmet une réponse négative avec ce NRC [SWS_Dcm_00463], [SWS_Dcm_00518].

Si, dans le cas de plusieurs notifications configurées, plusieurs fonctions retournent E_NOT_OK et aucune fonction ne retourne E_REQUEST_NOT_ACCEPTED, le sous-module DSD utilise obligatoirement pour la réponse négative le ErrorCode de la première fonction répondant avec E_NOT_OK [SWS_Dcm_01321], [SWS_Dcm_01322].

La fonction de rappel Xxx_Confirmation sert à notifier de manière synchrone à l’application la fin d’une transmission de diagnostic – soit l’émission réussie, soit une erreur de transmission ([SWS_Dcm_01342]). La déclaration est mise à disposition via le fichier d’en-tête Dcm_Externals.h ([SWS_Dcm_01342]).

Lors de l’appel par le sous-module DSD (Diagnostic Service Dispatcher) du DCM, des données de contexte essentielles de la requête de diagnostic sont transmises ([SWS_Dcm_01342], [SWS_Dcm_00741]) :

• SID : identifiant du service de diagnostic ([SWS_Dcm_01342]).
• ReqType : type d’adressage (0 pour physique, 1 pour fonctionnel) ([SWS_Dcm_01342]).
• ConnectionId, ProtocolType et TesterSourceAddress : attributs univoques de connexion et de protocole ainsi qu’adresse source du testeur ([SWS_Dcm_01342]).
• ConfirmationStatus : information d’état sur le succès ou l’échec de la transmission ([SWS_Dcm_01342]).

Comme valeur de retour, l’opération fournit Std_ReturnType (E_OK en cas de traitement réussi de la confirmation, sinon E_NOT_OK) ([SWS_Dcm_01342]). Le DSD appelle la fonction sur tous les ports qui utilisent l’interface ServiceRequestNotification (configurée via DcmDsdServiceRequestManufacturerNotification ou DcmDsdServiceRequestSupplierNotification) ([SWS_Dcm_00741]).

Concernant l’ordre des appels, Xxx_Confirmation est régulièrement exécutée directement après DspInternal_DcmConfirmation() ([SWS_Dcm_00742]). Cependant, dans le cas particulier selon [SWS_Dcm_01172], le DSD appelle exclusivement Xxx_Confirmation, tandis que l’appel interne n’a pas lieu.

Comme Xxx_Confirmation est spécifiée comme non réentrante (Non Reentrant) et synchrone ([SWS_Dcm_01342]), l’implémentation côté application ne devrait contenir aucun déroulement bloquant ni déclencher de rappels réentrants dans le DCM (interprétation). Question Q-58ce3e44dc61540b (ouverte)

Utilisation

La fonction de callout synchrone Xxx_ClearDTCCheckFnc est mise à disposition pour l'application via le fichier d'en-tête Dcm_Externals.h [SWS_Dcm_01270]. Elle sert à la vérification de conditions spécifiques au constructeur et au fournisseur avant l'effacement d'un groupe demandé de codes de défaut de diagnostic (Group of DTC). L'identifiant GoDTC de type uint32 lui est transmis en tant que paramètre d'entrée pour spécifier le groupe de codes de défaut à effacer [SWS_Dcm_01270].

Gestion des erreurs et valeurs de retour

L'autorisation de la demande d'effacement s'effectue via la valeur de retour de type Std_ReturnType en interaction avec le paramètre de sortie ErrorCode [SWS_Dcm_01270] :

• E_OK : l'application autorise l'effacement du groupe de codes de défaut demandé GoDTC [SWS_Dcm_01270].
• E_NOT_OK : l'application interdit l'effacement du groupe. Dans ce cas d'erreur, un code de réponse négatif doit être défini via le paramètre de sortie ErrorCode de type Dcm_NegativeResponseCodeType*. Le module DCM envoie ensuite une réponse négative avec la valeur de NRC indiquée dans ErrorCode [SWS_Dcm_01270].

Concurrence et restrictions

La fonction est pourvue de l'ID de service 0x5f, opère de manière synchrone et est définie comme non réentrante (Non Reentrant) [SWS_Dcm_01270]. Le contexte d'appel doit donc garantir que les appels s'effectuent séquentiellement et sans chevauchements concurrents.

La fonction de callout Xxx_ProcessRequestDownload ([SWS_Dcm_00754]) est appelée par le module Dcm afin d'initier une opération de téléchargement lors du traitement du service UDS RequestDownload. Elle est définie comme asynchrone et non réentrante, et est mise à disposition via l'en-tête Dcm_Externals.h ([SWS_Dcm_00754]).

Utilisation et paramètres

L'appel s'effectue étape par étape via le paramètre OpStatus avec les valeurs DCM_INITIAL, DCM_PENDING ou DCM_CANCEL ([SWS_Dcm_00754]). Les paramètres d'entrée transmis sont les méthodes de compression et de chiffrement (DataFormatIdentifier), le bloc mémoire (MemoryIdentifier), l'adresse de départ (MemoryAddress) et la taille de la mémoire non compressée en octets (MemorySize) ([SWS_Dcm_00754]). Avant l'appel, le Dcm écrit la taille maximale possible du tampon dans le paramètre inout BlockLength ([SWS_Dcm_01417]). La fonction ajuste cette valeur à la longueur de bloc maximale autorisée pour les futures opérations d'écriture ([SWS_Dcm_00754]).

Valeurs de retour et interaction

La fonction retourne E_OK en cas d'exécution réussie, DCM_E_PENDING si le traitement est encore en cours, ou E_NOT_OK en cas d'erreur ([SWS_Dcm_00754]) :

• Si l'appel retourne E_OK et que la valeur négociée BlockLength est inférieure ou égale à la longueur de tampon prise en charge par la connexion de protocole actuelle, le Dcm envoie une réponse positive avec cette valeur comme maxNumberOfBlockLength ([SWS_Dcm_01419]).
• Si la longueur de tampon retournée dépasse la taille de tampon prise en charge par la connexion de protocole, le Dcm signale l'erreur DET DCM_E_INTERFACE_BUFFER_OVERFLOW ([SWS_Dcm_01418]).
• En cas de retour de E_NOT_OK, le Dcm envoie une réponse négative UDS (NRC) avec la valeur définie dans le paramètre de sortie ErrorCode ([SWS_Dcm_00754], [SWS_Dcm_00757]).

La fonction de callout Xxx_ProcessRequestTransferExit est appelée par le module DCM afin de mettre fin à un processus de téléchargement ou de téléversement en cours dans le cadre du service UDS RequestTransferExit [SWS_Dcm_00755]. La déclaration de l'interface est fournie via l'en-tête Dcm_Externals.h [SWS_Dcm_00755].

Utilisation et sémantique

La fonction fonctionne de manière asynchrone et est définie comme non réentrante [SWS_Dcm_00755]. L'appel s'effectue en transmettant l'état d'exécution actuel OpStatus (valeurs possibles : DCM_INITIAL, DCM_PENDING ou DCM_CANCEL) [SWS_Dcm_00755]. Sont spécifiées comme valeurs de retour de type Std_ReturnType :

• E_OK : le transfert s'est terminé avec succès [SWS_Dcm_00755].
• DCM_E_PENDING : l'arrêt du transfert n'est pas encore terminé et nécessite des appels consécutifs [SWS_Dcm_00755].
• E_NOT_OK : l'arrêt a échoué ou le tampon de réponse est trop petit [SWS_Dcm_00755].

Traitement des erreurs et interaction

Si l'opération Xxx_ProcessRequestTransferExit renvoie la valeur d'erreur E_NOT_OK, un code de réponse négative doit être transmis via le paramètre de sortie ErrorCode. Le module DCM envoie alors une réponse négative UDS (NRC) avec précisément ce code d'erreur à l'outil de diagnostic [SWS_Dcm_00759]. Lors d'un appel d'interruption, le module DCM transmet l'état DCM_CANCEL à la fonction [SWS_Dcm_00755].