Intrusion Detection System Manager (IdsM)

L'interface synchrone et non réentrante IdsM_Init sert à l'initialisation de base du module IdsM conformément à [SWS_IdsM_91001]. Lors de l'appel, le service initialise l'ensemble des variables internes et fait passer l'IdsM à l'état initialisé ([SWS_IdsM_00202]). Via le paramètre d'entrée configPtr, la fonction reçoit un pointeur vers la structure de configuration spécifique au module ([SWS_IdsM_91001]).

L'exécution de IdsM_Init constitue une précondition fonctionnelle impérative pour le fonctionnement du module. Si une API de l'IdsM autre que IdsM_Init ou IdsM_GetVersionInfo est appelée alors que l'état n'est pas encore initialisé, le module signale l'erreur IDSM_E_PARAM_UNINIT via Det_ReportError lorsque la détection des erreurs de développement (IdsMDevErrorDetect) est activée ([SWS_IdsM_00203], voir également le code d'erreur 0x0D sous [SWS_IdsM_02003]).

Des règles de comportement spécifiques s'appliquent au traitement des erreurs et au contexte d'appel :

• Si IdsM_Init est appelée alors que le module se trouve déjà dans l'état initialisé, aucune réinitialisation des variables internes n'est effectuée ([SWS_IdsM_00204]).
• À la place, si IdsMDevErrorDetect est activé, le module signale via Det_ReportError l'erreur de développement IDSM_E_ALREADY_INITIALIZED avec la valeur numérique 0x0E ([SWS_IdsM_00204], [SWS_IdsM_02003]).
• La fonction n'a pas de valeur de retour et est définie comme non réentrante ([SWS_IdsM_91001]). Elle ne doit donc pas être appelée plusieurs fois simultanément dans le système de manière concurrente ou par le biais de contextes interruptifs.

Utilisation et contexte d'appel

La fonction IdsM_MainFunction est appelée périodiquement et est disponible via le fichier d'en-tête IdsM.h [SWS_IdsM_91000]. Elle possède la signature void IdsM_MainFunction(void), ne prend aucun paramètre et ne possède aucune valeur de retour [SWS_IdsM_91000]. L'appel de la fonction elle-même est synchrone, mais sert au traitement asynchrone d'événements de sécurité (Security Events, SEv) qui ont été préalablement placés dans des files d'attente lors d'appels d'API synchrones [SWS_IdsM_91000]. Le déclenchement périodique devrait typiquement être effectué par l'ordonnanceur BSW ou par une tâche cyclique du système d'exploitation. Question Q-86e2e870c3496bad (ouverte)

Concurrence et restrictions

Conformément à la spécification, IdsM_MainFunction est classée comme non réentrante (Non Reentrant) [SWS_IdsM_91000]. L'environnement système appelant doit donc garantir que la fonction n'est exécutée à tout moment que dans une seule instance et qu'aucun appel chevauchant n'a lieu.

Interaction lors du traitement des événements

La tâche principale dans le cadre du traitement cyclique comprend les aspects suivants :

• Tampons d'événements : après la réception d'un SEv, l'IdsM enregistre celui-ci dans un Event Buffer ; ces tampons sont gérés et filtrés de manière asynchrone dans le cadre de IdsM_MainFunction [SWS_IdsM_00702].
• Tampons de données de contexte : si un SEv comportant des données de contexte est reçu, l'IdsM utilise des tampons appropriés provenant d'un Context Data Buffer Pool ; ces tampons sont également manipulés et filtrés de manière asynchrone dans IdsM_MainFunction [SWS_IdsM_00705].
• Qualification : les SEv enregistrés dans les Event Buffers sont traités de manière asynchrone afin de les identifier comme événements de sécurité qualifiés (QSEv) [SWS_IdsM_00901].

La fonction de rappel est appelée de manière synchrone et réentrante afin de récupérer des données d'émission pour les segments d'une I-PDU (N-PDU) [SWS_IdsM_91010]. Elle est disponible via l'en-tête IdsM_Cbk.h et dessert l'identifiant de service 0x43 [SWS_IdsM_91010].

L'I-PDU à transmettre est identifiée via id [SWS_IdsM_91010]. Le paramètre info transmet le tampon de destination (SduDataPtr) ainsi que la longueur en octets demandée (SduLength) ; une valeur de 0 pour SduLength (SduDataPtr pouvant être un NULL_PTR) sert aux changements d'état dans le paramètre retry ou à la consultation des données restantes [SWS_IdsM_91010]. La fonction renvoie via availableDataPtr la quantité de données restant dans le tampon Tx, ce qui permet aux protocoles de transport avec des longueurs utiles dynamiques (par ex. FrIsoTp) de déterminer la taille des Consecutive Frames consécutives [SWS_IdsM_91010].

Si retry est un NULL_PTR, les données copiées peuvent être libérées du tampon immédiatement après l'opération de copie [SWS_IdsM_91010]. Sinon, RetryInfoType contrôle le traitement des erreurs : avec TP_CONFPENDING, les données copiées précédemment restent dans le tampon TP, tandis que TP_DATACONF confirme et libère toutes les données copiées avant cet appel [SWS_IdsM_91010]. Si TpDataState est positionné sur TP_DATARETRY, la fonction copie à nouveau les données transmises précédemment à partir de l'offset d'octet spécifié par TxTpDataCnt [SWS_IdsM_91010].

La fonction retourne BUFREQ_OK en cas de copie complète réussie [SWS_IdsM_91010]. Si le volume de données d'émission disponible est insuffisant, aucune donnée n'est copiée et BUFREQ_E_BUSY est renvoyé, à la suite de quoi le module sous-jacent peut répéter l'appel [SWS_IdsM_91010]. En cas d'échec de la requête, BUFREQ_E_NOT_OK est renvoyé sans reprise de données [SWS_IdsM_91010].

La fonction IdsM_SetSecurityEvent sert d'interface permettant aux applications de notifier des événements de sécurité au module IdsM (Intrusion Detection System Manager) [SWS_IdsM_91002].

Utilisation et contexte d'appel

L'appel s'effectue de manière synchrone via le fichier d'en-tête IdsM.h avec l'ID de service 0x03 [SWS_IdsM_91002]. L'identifiant de l'événement de sécurité est transmis comme unique paramètre :

• securityEventId (IN, IdsM_SecurityEventIdType) : identifiant unique de l'événement de sécurité notifié [SWS_IdsM_91002].

La fonction ne possède pas de valeur de retour (void) [SWS_IdsM_91002].

Gestion des erreurs

Si la détection des erreurs de développement (IdsMDevErrorDetect) est activée, le module vérifie le paramètre securityEventId par rapport aux événements de sécurité configurés [SWS_IdsM_02101]. Si un ID d'événement inconnu non configuré dans IdsMEvent est transmis, l'IdsM signale l'erreur de développement IDSM_E_PARAM_INVALID [SWS_IdsM_02101].

Concurrence et restrictions

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_IdsM_91002]. Les appels concurrents ou interruptifs issus de différents contextes doivent donc être synchronisés ou évités par l'appelant.

La fonction IdsM_SetSecurityEventWithContextData sert d'interface applicative pour le signalement synchrone d'événements de sécurité accompagnés de données de contexte optionnelles à l'Intrusion Detection System Manager ([SWS_IdsM_91003]). Elle ne possède pas de valeur de retour.

Paramètres et utilisation

• securityEventId : identifiant univoque de l'événement de sécurité signalé ([SWS_IdsM_91003]).
• contextData : pointeur vers des données de contexte optionnelles ; si aucune donnée de contexte n'est disponible, NULL_PTR doit être transmis ([SWS_IdsM_91003]).
• contextDataSize : taille des données de contexte fournies en octets ([SWS_IdsM_91003]).

Gestion des erreurs

Lorsque la détection de développement est activée (IdsMDevErrorDetect), le module IdsM effectue les vérifications suivantes :

• Si l'securityEventId transmise ne provient pas des événements de sécurité configurés dans IdsMEvent, l'erreur de développement IDSM_E_PARAM_INVALID est signalée ([SWS_IdsM_02102]).
• Si contextDataSize dépasse la taille maximale de tampon configurée pour les données de contexte (définie par la plus grande valeur paramétrée de IdsMContextDataBufferSize), l'erreur de développement IDSM_E_PARAM_LENGTH est signalée ([SWS_IdsM_02107]).

Concurrence et intégration

L'interface est spécifiée comme non réentrante (Non Reentrant) ([SWS_IdsM_91003]). Les appelants doivent donc s'assurer que les appels concurrents sont évités ou synchronisés de manière appropriée. La déclaration est disponible via l'en-tête IdsM.h ([SWS_IdsM_91003]).

La fonction synchrone IdsM_SetSecurityEventWithCount (identifiant de service 0x05) constitue l'interface applicative permettant aux Smart Sensors de transmettre des événements de sécurité (Security Events, SEvs) accompagnés d'une valeur de compteur à l'IdsM [SWS_IdsM_91018], [SWS_IdsM_00401]. Cela permet à l'IdsM de recevoir des événements avec un compteur précalculé par le capteur [SWS_IdsM_00401]. La déclaration de la fonction est fournie via le fichier d'en-tête IdsM.h [SWS_IdsM_91018].

Lors de l’appel, la fonction attend deux paramètres d’entrée :

• securityEventId : identifiant de l'événement de sécurité de type IdsM_SecurityEventIdType [SWS_IdsM_91018].
• count : valeur de compteur de type uint16 provenant du capteur et servant de valeur initiale de départ pour l'événement [SWS_IdsM_91018], [SWS_IdsM_00401].

La fonction ne fournit aucune valeur de retour et ne définit aucun paramètre de sortie [SWS_IdsM_91018]. En matière de concurrence et de contexte d'appel, la fonction est déclarée comme non réentrante (Non Reentrant) [SWS_IdsM_91018] ; les appels parallèles doivent donc être évités du côté logiciel.

Pour le traitement des erreurs, il est défini que l'IdsM vérifie les paramètres securityEventId et count lorsque la détection des erreurs de développement (IdsMDevErrorDetect) est activée [SWS_IdsM_02103]. Si un ID d'événement inconnu est transmis ou si count a la valeur 0, l'erreur de développement IDSM_E_PARAM_INVALID est signalée [SWS_IdsM_02103].

La fonction IdsM_SetSecurityEventWithCountContextData sert d'interface d'application pour les capteurs intelligents pour la notification synchrone d'événements de sécurité à l'[SWS_IdsM_91019] avec valeur de compteur et données de contexte optionnelles.

Utilisation et paramètres

L'appel s'effectue de manière synchrone et est spécifié comme non réentrant (Non Reentrant) [SWS_IdsM_91019] :

• securityEventId : identifiant unique de l'événement de sécurité [SWS_IdsM_91019].
• count : valeur de compteur utilisée comme valeur initiale pour l'événement de sécurité [SWS_IdsM_91019].
• contextData : pointeur vers un tableau d'octets contenant les données de contexte à fournir [SWS_IdsM_00502]. En l'absence de données de contexte, NULL_PTR doit être transmis [SWS_IdsM_91019].
• contextDataSize : taille en octets des données de contexte transmises [SWS_IdsM_91019]. La fonction prend en charge une longueur maximale allant jusqu'à 1500 octets [SWS_IdsM_00501].

Gestion des erreurs

Lorsque la détection des erreurs de développement (IdsMDevErrorDetect) est activée, le module surveille la validité des arguments transmis :

• L'erreur de développement IDSM_E_PARAM_INVALID est signalée si un securityEventId inconnu est transmis ou si count présente la valeur 0 [SWS_IdsM_02104].
• Si contextDataSize dépasse la taille de tampon maximale configurée (déterminée par la plus grande IdsMContextDataBufferSize configurée), l'IdsM signale l'erreur de développement IDSM_E_PARAM_LENGTH [SWS_IdsM_02108].

La fonction ne renvoie aucune valeur de retour [SWS_IdsM_91019] ; en cas d'erreur, la réaction face aux erreurs devrait reposer principalement sur la notification via le DET. Question Q-135f4b865790f34d (ouverte)

L'interface synchrone IdsM_SetSecurityEventWithTimestampCount permet aux Smart Sensors de signaler des événements de sécurité avec un horodatage et une valeur de compteur à l'IdsM [SWS_IdsM_91020]. La fonction ne possède aucune valeur de retour et est disponible via le fichier d'en-tête IdsM.h [SWS_IdsM_91020].

Les paramètres d'entrée suivants sont traités :

• securityEventId : identifiant spécifique de l'événement de sécurité signalé [SWS_IdsM_91020].
• timestamp : horodatage pour la référence temporelle de l'événement [SWS_IdsM_91020]. Si la fonctionnalité d'horodatage est active et qu'un horodatage est transmis, l'IdsM l'utilise pour le stockage ou la transmission du Security Event qualifié (QSEv) [SWS_IdsM_01108]. En revanche, si l'événement est signalé sans horodatage alors que la fonctionnalité est active, l'IdsM met à 0 le bit d'option pour l'horodatage dans l'en-tête de protocole avant la transmission ou le stockage [SWS_IdsM_01112].
• count : valeur de compteur servant de valeur de départ pour l'événement de sécurité [SWS_IdsM_91020]. Si aucun compteur calculé n'est disponible au préalable, la fonction peut être appelée avec la valeur 1 [SWS_IdsM_00405].

Lorsque la détection des erreurs de développement (IdsMDevErrorDetect) est activée, l'IdsM valide les arguments securityEventId et count. Si un ID d'événement inconnu est transmis ou si count a la valeur 0, le module signale l'erreur de développement IDSM_E_PARAM_INVALID [SWS_IdsM_02105].

En ce qui concerne la concurrence, la fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_IdsM_91020].

La fonction IdsM_SetSecurityEventWithTimestampCountContextData dotée de l'identifiant de service 0x08 sert d'interface applicative standardisée pour les Smart Sensors afin de signaler des événements de sécurité accompagnés d'un horodatage, d'une valeur initiale de compteur ainsi que de données de contexte facultatives à l'Intrusion Detection System Manager (IdsM) [SWS_IdsM_91021]. La déclaration de cette interface est mise à disposition via l'en-tête IdsM.h [SWS_IdsM_91021].

L'appel est exécuté de manière synchrone et utilise exclusivement des paramètres d'entrée, tandis qu'il n'existe ni paramètre d'entrée/sortie ni paramètre de sortie [SWS_IdsM_91021]. Lors de l'appel, les paramètres suivants doivent être transmis [SWS_IdsM_91021] :

• securityEventId : identifiant de l'événement de sécurité spécifique devant être transmis à l'IdsM [SWS_IdsM_91021].
• timestamp : valeur d'horodatage servant de référence temporelle de l'événement de sécurité survenu [SWS_IdsM_91021].
• count : valeur de compteur utilisée par l'IdsM comme valeur de départ pour l'événement de sécurité respectif [SWS_IdsM_91021].
• contextData : pointeur vers des données de contexte facultatives relatives à l'événement ; si aucune donnée n'est disponible, NULL_PTR doit être transmis [SWS_IdsM_91021].
• contextDataSize : indication numérique de la taille des données de contexte transmises [SWS_IdsM_91021].

Concernant le comportement d'exécution, la fonction est classée comme non réentrante (Non Reentrant) et ne possède aucune valeur de retour (void) [SWS_IdsM_91021]. Les Smart Sensors appelants doivent donc s'assurer qu'aucun appel simultané ou chevauchant de l'interface n'a lieu [SWS_IdsM_91021].

La fonction de rappel IdsM_BswM_StateChanged ([SWS_IdsM_91005]) est appelée par le BswM pour signaler à l'Intrusion Detection System Manager (IdsM) les modifications de l'état actuel du calculateur ([SWS_IdsM_91005]). Elle est déclarée dans le fichier d'en-tête IdsM_Cbk.h et possède l'ID de service 0x0F ([SWS_IdsM_91005]).

L'interface possède la signature void IdsM_BswM_StateChanged (IdsM_Filters_BlockStateType state) ([SWS_IdsM_91005]). Le paramètre d'entrée state de type IdsM_Filters_BlockStateType, qui représente l'état actuel de l'ECU ([SWS_IdsM_91005]), sert d'unique valeur de transmission. Aucun paramètre d'entrée/sortie ni aucun paramètre de sortie n'est prévu, et la fonction ne renvoie aucune valeur de retour ([SWS_IdsM_91005]). L'appel est exécuté de manière synchrone et est classé comme réentrant ([SWS_IdsM_91005]).

Dans le cadre de l'interaction fonctionnelle, ce service de notification permet au BswM d'informer en continu l'IdsM de l'état actuel ([SWS_IdsM_01022]). L'information d'état reçue est conservée dans l'IdsM et évaluée lors du traitement asynchrone ultérieur des filtres Block State (block state filter) dans le cadre de la fonction principale (main function) [SWS_IdsM_01022]. Aucun code d'erreur spécifique, valeur de retour ou notification vers la gestion des erreurs de développement (DET) ou la gestion des événements de diagnostic (DEM) n'est défini pour cet appel dans le périmètre de la spécification.

La fonction de rappel IdsM_TpTxConfirmation est déclarée comme un service synchrone et réentrant via le fichier d'en-tête IdsM_Cbk.h [SWS_IdsM_91011]. Conformément à [SWS_IdsM_01502], le module IdsM reçoit via ce service la confirmation du module PduR pour la transmission d'une PDU segmentée. L'appel a lieu dès que l'I-PDU concernée a été transmise sur le réseau sous-jacent [SWS_IdsM_91011].

L'interface possède l'identifiant de service 0x48 et ne renvoie aucune valeur de retour (void) [SWS_IdsM_91011]. Deux paramètres d'entrée sont transmis lors de l'appel :

• id (type PduIdType) : identification unique de l'I-PDU transmise [SWS_IdsM_91011].
• result (type Std_ReturnType) : transmet le résultat de la transmission de l'I-PDU et indique si l'opération d'émission a réussi ou a échoué [SWS_IdsM_91011].

Aucun code d'erreur spécifique ni message DET ou DEM n'est défini pour cet appel dans la spécification. Grâce à la réentrance spécifiée, la fonction peut être appelée en parallèle pour différentes I-PDU par la couche appelante [SWS_IdsM_91011]. Interprétation : le module IdsM devrait évaluer le paramètre d'état result pour mettre à jour l'état de transmission interne de la PDU segmentée et libérer les tampons d'émission occupés une fois l'opération terminée. Question Q-9179efcbf744346d (ouverte)

Utilisation

La fonction de rappel IdsM_TxConfirmation ([SWS_IdsM_91009]) est appelée par un module d'interface de communication sous-jacent pour confirmer la transmission réussie d'une PDU ou l'échec de la transmission. Elle est définie comme synchrone, déclarée dans IdsM_Cbk.h et ne possède aucune valeur de retour. Elle accepte les paramètres suivants :

• TxPduId : identifiant de la PDU transmise ([SWS_IdsM_91009]).
• result : résultat de la transmission avec E_OK en cas d'envoi réussi ou E_NOT_OK en cas d'erreur survenue ([SWS_IdsM_91009]).

Concurrence et restrictions

La fonction est réentrante pour différents ID de PDU, mais non réentrante pour le même TxPduId ([SWS_IdsM_91009]).

Interaction et conditions d'ordonnancement

Une contrainte d'ordonnancement stricte s'applique à la séquence de transmission : conformément à [SWS_IdsM_01499], l'IdsM n'est autorisé à appeler de nouveau la fonction d'émission PduR_IdsMTransmit qu'après l'appel préalable de IdsM_TxConfirmation ou IdsM_TpTxConfirmation. Interprétation : l'arrivée de la confirmation devrait servir de déclencheur au sein de l'IdsM pour terminer la transmission et autoriser les appels ultérieurs. Question Q-dd4013520e85370c (ouverte)

Gestion des erreurs

Un échec de la transmission de PDU est signalé directement par le paramètre result = E_NOT_OK ([SWS_IdsM_91009]). Aucun code d'erreur DET ou DEM spécifique n'est indiqué dans la spécification de l'interface.

Utilisation et contexte d'appel

La fonction synchrone IdsM_Dcm_GetReportingMode_RequestResults (ID de service 0x0D, en-tête IdsM_Cbk.h) est appelée par le Diagnostic Communication Manager (DCM) pour interroger les résultats de routine d'une requête préalablement initiée via IdsM_Dcm_GetReportingMode_Start() [SWS_IdsM_91007]. L'état d'opération actuel est transmis via le paramètre de transmission OpStatus [SWS_IdsM_91007]. En cas d'achèvement réussi, la fonction renvoie E_OK et délivre via le pointeur de sortie Out_ReportingMode le mode de reporting déterminé pour l'événement de sécurité demandé [SWS_IdsM_91007]. Si le traitement n'est pas encore terminé, elle le signale via la valeur de retour DCM_E_PENDING [SWS_IdsM_91007].

Gestion des erreurs

Si l'interrogation échoue, la fonction renvoie E_NOT_OK [SWS_IdsM_91007]. Dans ce cas, un Negative Response Code (Dcm_NegativeResponseCodeType) concret doit être défini via le paramètre ErrorCode ; s'il n'est pas défini, le DCM transmet le code d'erreur 0x22 [SWS_IdsM_91007]. Aucun événement DET ou DEM spécifique n'est désigné pour ce service [SWS_IdsM_91007].

Concurrence et interaction

La fonction est spécifiée comme réentrante [SWS_IdsM_91007]. Concernant la séquence d'appels, elle exige impérativement que la routine ait été préalablement déclenchée au moyen de IdsM_Dcm_GetReportingMode_Start() [SWS_IdsM_91007]. Interprétation : le paramètre OpStatus devrait être utilisé par le DCM lors d'interrogations répétées après le retour de DCM_E_PENDING afin de coordonner l'avancement de l'opération de diagnostic. Question Q-c268fab018a1f5b3 (ouverte)

La fonction IdsM_Dcm_GetReportingMode_Start est appelée par le module de diagnostic (DCM) afin de démarrer, dans l'Intrusion Detection System Manager (IdsM), l'exécution d'une routine d'interrogation du mode de rapport actuel d'un événement de sécurité spécifique (SEv) [SWS_IdsM_91006], [SWS_IdsM_02001]. L'interface est déclarée dans l'en-tête IdsM_Cbk.h, possède l'identifiant de service 0x0C et est spécifiée comme synchrone et réentrante [SWS_IdsM_91006].

Lors de l'appel, le DCM transmet l'ID externe de l'événement de sécurité (In_SecurityEventId), l'ID d'instance du capteur (In_SensorInstanceId) et l'état de l'opération (OpStatus) [SWS_IdsM_91006]. Comme valeur de retour, la fonction fournit Std_ReturnType :

• E_OK : l'opération s'est achevée avec succès [SWS_IdsM_91006].
• DCM_E_PENDING : l'opération n'est pas encore terminée [SWS_IdsM_91006]. Cela devrait signifier que le traitement interne de la routine se poursuit sur plusieurs cycles ou de manière asynchrone jusqu'à ce que les données soient disponibles. Question Q-395a30fc3ed42497 (ouverte)
• E_NOT_OK : l'opération a échoué [SWS_IdsM_91006].

En cas d'erreur (E_NOT_OK), l'IdsM est tenu de fournir un Negative Response Code (NRC) concret via le paramètre de sortie ErrorCode ; si tel n'est pas le cas, le DCM envoie par défaut le NRC 0x22 (Conditions Not Correct) [SWS_IdsM_91006].

La fonction déclenche uniquement la routine ; la lecture effective des résultats déterminés s'effectue ensuite par le biais de la fonction IdsM_Dcm_GetReportingMode_RequestResults [SWS_IdsM_91007].

La fonction synchrone et réentrante IdsM_Dcm_SetReportingMode_Start est appelée par le module de diagnostic (DCM) pour démarrer la routine de modification du mode de rapport (IdsMReportingModeFilter) pour un événement de sécurité spécifique dans l'Intrusion Detection System Manager [SWS_IdsM_91008], [SWS_IdsM_01901]. La déclaration est fournie via le fichier d'en-tête IdsM_Cbk.h [SWS_IdsM_91008].

Lors de l'appel, l'ID d'événement externe (In_SecurityEventId), l'ID d'instance de capteur (In_SensorInstanceId), le nouveau mode de rapport à définir (In_ReportingMode) ainsi que l'état d'opération (OpStatus) sont transmis [SWS_IdsM_91008], [SWS_IdsM_01901]. La fonction fournit les valeurs de retour suivantes :

• E_OK : l'exécution de l'opération s'est terminée avec succès [SWS_IdsM_91008].
• DCM_E_PENDING : le traitement n'est pas encore terminé et se poursuit de manière asynchrone [SWS_IdsM_91008].
• E_NOT_OK : l'opération a échoué ; dans ce cas, un Negative Response Code (NRC) concret doit être défini via le paramètre de sortie ErrorCode, faute de quoi le DCM transmet le NRC 0x22 [SWS_IdsM_91008].

Si la validation de l'ID d'événement échoue en raison de l'utilisation d'un Security Event Definition ID non valide, la fonction renvoie E_NOT_OK et définit obligatoirement le code d'erreur ErrorCode à DCM_E_REQUESTOUTOFRANGE [SWS_IdsM_01903].

Le type de données IdsM_Filters_BlockStateType sert à définir des masques de bits pour les filtres d'état de blocage (« Block State ») de l'Intrusion Detection System Manager (IdsM) conformément à [SWS_IdsM_91017]. Le type est dérivé de uint16, couvre la plage de valeurs entières de 0 à 65535 et est mis à disposition des modules logiciels via l'en-tête IdsM_Filters_Types.h ([SWS_IdsM_91017]).

L'utilisation principale s'effectue en interaction avec le Basic Software Mode Manager (BswM). Lors de modifications de l'état du système ou du calculateur, le BswM appelle la fonction de rappel IdsM_BswM_StateChanged et transmet l'état actuel du calculateur via le paramètre state de ce type ([SWS_IdsM_91005]). Cette interface de rappel est déclarée dans IdsM_Cbk.h, ne renvoie aucune valeur de retour et est spécifiée comme synchrone et réentrante ([SWS_IdsM_91005]).

Interprétation : le type étant conçu comme un masque de bits pour les filtres, l'IdsM devrait comparer la valeur d'état d'ECU transmise avec les états de filtrage configurés afin de filtrer la collecte ou le blocage des événements de sécurité en fonction de l'état du calculateur. Question Q-00b355cc5ec6383f (ouverte) Il n'existe pas de traitement d'erreur autonome avec des codes d'erreur, des messages DET ou DEM spécifiques pour ce type de données.

Le type de données IdsM_Filters_ReportingModeType repose sur le type de base uint8 et est mis à disposition des composants logiciels via le fichier d'en-tête IdsM_Types.h [SWS_IdsM_91013]. Il décrit les modes de rapport standardisés qui sont appliqués au sein du filtre de mode de rapport dans l'Intrusion Detection System Manager (IdsM) pour le traitement et le transfert ciblés des événements de sécurité [SWS_IdsM_91013].

Les valeurs d'énumération définies permettent de contrôler précisément si un événement est signalé et quel niveau de détail est alors utilisé [SWS_IdsM_91013] :

• IDSM_REPORTING_MODE_OFF (0x00) : l'événement est supprimé et n'est pas signalé aux instances de niveau supérieur [SWS_IdsM_91013].
• IDSM_REPORTING_MODE_BRIEF (0x01) : l'événement est signalé sous forme compacte sans données de contexte supplémentaires [SWS_IdsM_91013].
• IDSM_REPORTING_MODE_DETAILED (0x02) : l'événement est signalé de manière détaillée en incluant toutes les données de contexte pertinentes [SWS_IdsM_91013].
• IDSM_REPORTING_MODE_BRIEF_BYPASSING_FILTERS (0x03) : l'événement contourne les étapes de filtrage ultérieures et est signalé sans données de contexte, sans être filtré [SWS_IdsM_91013].
• IDSM_REPORTING_MODE_DETAILED_BYPASSING_FILTERS (0x04) : l'événement contourne les étapes de filtrage ultérieures et est signalé sans filtrage, y compris l'ensemble des données de contexte [SWS_IdsM_91013].
• IDSM_REPORTING_MODE_INVALID (0xFF) : désigne un mode de rapport invalide dans la plage de valeurs [SWS_IdsM_91013].

Les valeurs combinent ainsi deux dimensions de commande fonctionnelle : le niveau de détail via les données de contexte ainsi que le contournement ciblé des mécanismes de filtrage réguliers par le contournement (bypassing) [SWS_IdsM_91013]. Cela permet à l'IdsM un traitement différencié des incidents de sécurité selon la criticité et la configuration du filtrage [SWS_IdsM_91013].