ECU State Manager (EcuM)

La fonction synchrone et réentrante EcuM_GoDownHaltPoll demande au module ECU State Manager de passer dans un mode Sleep, en Reset ou dans l'état OFF selon la cible d'arrêt préalablement sélectionnée [SWS_EcuM_91002]. Elle est disponible via le fichier d'en-tête EcuM.h et possède l'ID de service 0x2c [SWS_EcuM_91002].

Paramètres et autorisation d'appel

UserID de type EcuM_UserType est transmis comme unique paramètre d'entrée. Celui-ci identifie l'utilisateur appelant. L'appel est strictement réglementé : seuls des utilisateurs préconfigurés sont autorisés à exécuter cette fonction [SWS_EcuM_91002].

Valeurs de retour et comportement d'exécution

Le comportement de retour dépend essentiellement de la nature de la cible d'arrêt définie [SWS_EcuM_91002] :

• E_NOT_OK : la demande n'a pas été acceptée [SWS_EcuM_91002].
• E_OK : si la cible est SLEEP, la fonction retourne ce statut avec succès après la sortie de l'état de veille [SWS_EcuM_91002].
• Aucun retour : si RESET ou OFF a été sélectionné comme cible d'arrêt, l'appel de fonction ne retourne plus vers l'appelant [SWS_EcuM_91002].

Restrictions et traitement des erreurs

Bien que la fonction soit formellement déclarée comme réentrante, son exécution conforme nécessite la définition préalable d'une cible d'arrêt valide [SWS_EcuM_91002]. Aucun code d'erreur DET ou DEM spécifique n'est répertorié dans la spécification d'interface ; un échec ou le rejet de la requête est directement indiqué par la valeur de retour E_NOT_OK [SWS_EcuM_91002].

La fonction de service synchrone EcuM_Init initialise l'ECU State Manager et lance la séquence de démarrage ordonnée du calculateur ([SWS_EcuM_02811]). Elle est déclarée via l'en-tête EcuM.h avec l'ID de service 0x01, ne prend aucun paramètre et ne fournit aucune valeur de retour ([SWS_EcuM_02811]). Formellement classée comme réentrante, EcuM_Init ne retourne jamais à l'appelant après son appel, car elle transfère l'exécution au système d'exploitation en appelant StartOS ([SWS_EcuM_02811]).

Dans le cadre de son exécution, la fonction traite la séquence StartPreOS définie ainsi que ses activités dans l'ordre exactement prescrit ([SWS_EcuM_02411], [SWS_EcuM_02684]). Une composante essentielle de cette phase est la vérification de la cohérence de configuration : le module vérifie au sein de EcuM_Init si le champ de structure correspondant est identique à la valeur de ECUM_CONFIGCONSISTENCY_HASH ([SWS_EcuM_02798]).

De plus, EcuM_Init contrôle l'initialisation des pilotes sur les systèmes multicœurs ([SWS_EcuM_04145]). La fonction appelle les callouts EcuM_AL_DriverInitZero ainsi que EcuM_AL_DriverInitOne sur chaque cœur individuel ([SWS_EcuM_04145]). Pour les implémentations de callouts, la consigne s'applique de s'assurer que seuls les modules MCAL effectivement exécutés sur le cœur actif correspondant y sont initialisés ([SWS_EcuM_04145]).

La fonction synchrone et non réentrante EcuM_StartupTwo implémente l’état STARTUP II de l’ECU State Manager [SWS_EcuM_02838]. L’interface est déclarée via le fichier d’en-tête EcuM.h et possède le Service-ID 0x1a [SWS_EcuM_02838]. Conformément à la signature de la fonction void EcuM_StartupTwo(void), l’appel n’accepte ni paramètre d’entrée, ni d’entrée/sortie, ni de sortie, et ne renvoie aucune valeur de retour à l’appelant [SWS_EcuM_02838].

Si le module ECU Manager est activé par la fonction EcuM_StartupTwo, il exécute les actions de la séquence StartPostOS [SWS_EcuM_02932].

Pour l’intégration, des exigences essentielles s’appliquent concernant le contexte d’appel et la concurrence : la fonction doit impérativement être appelée depuis une tâche démarrée directement en conséquence de StartOS [SWS_EcuM_02806]. Cela nécessite que l’appel de EcuM_StartupTwo provienne soit d’une tâche à démarrage automatique (Autostart), soit d’une tâche démarrée explicitement [SWS_EcuM_02806]. Comme la fonction est spécifiée comme non réentrante, aucun appel simultané ou multiple ne doit avoir lieu [SWS_EcuM_02838].

La fonction de service synchrone EcuM_Shutdown (Service-ID 0x02) est mise à disposition via le fichier d’en-tête EcuM.h et prend en charge le contrôle d’exécution pour la réalisation des activités de la phase « GO OFF II » [SWS_EcuM_02812]. Elle sert à la terminaison finale du processus d’arrêt [SWS_EcuM_02953].

Contexte d'appel et sémantique

Typiquement, la fonction est appelée depuis le Shutdown-Hook [SWS_EcuM_02812]. Conformément aux exigences, ce hook est explicitement tenu d’appeler EcuM_Shutdown afin de terminer le processus d’arrêt [SWS_EcuM_02953].

• Signature : void EcuM_Shutdown(void) avec le Service-ID 0x02 [SWS_EcuM_02812].
• Paramètres : il n’existe aucun paramètre d’entrée, de sortie ou d’entrée/sortie [SWS_EcuM_02812].
• Valeur de retour : l’interface ne renvoie aucune valeur de retour [SWS_EcuM_02812].
• Synchronicité : l’appel est exécuté de manière synchrone [SWS_EcuM_02812].

Concurrence et flux de contrôle

Dans la spécification, EcuM_Shutdown est déclarée comme réentrante [SWS_EcuM_02812]. Pour le déroulement du programme, il existe cependant l’exigence stricte selon laquelle EcuM_Shutdown ne doit pas retourner vers l’appelant [SWS_EcuM_02953]. Après son exécution, la fonction éteint définitivement le calculateur ou déclenche alternativement une réinitialisation [SWS_EcuM_02953].

Utilisation et contexte d'appel

La fonction synchrone EcuM_SetState permet au BswM de communiquer un changement d'état à l'EcuM [SWS_EcuM_04122]. Le paramètre d'entrée transmis est state de type EcuM_StateType, qui spécifie l'état imposé par le BswM [SWS_EcuM_04122]. La fonction ne possède aucune valeur de retour [SWS_EcuM_04122].

Fonctionnement et interaction

Lors de l'appel, la fonction définit l'état interne de l'EcuM à la valeur du paramètre state [SWS_EcuM_04123]. Si le BswM définit de cette manière un état de l'EcuM, l'EcuM indique le mode correspondant à la RTE [SWS_EcuM_04116].

Gestion des erreurs

Si la valeur transmise du paramètre state n'est pas valide, EcuM_SetState ne modifie pas l'état de l'EcuM [SWS_EcuM_04123]. Si le Development Error Reporting est activé, la fonction signale en plus, dans ce cas d'erreur, l'erreur ECUM_E_STATE_PAR_OUT_OF_RANGE au module DET [SWS_EcuM_04123].

Concurrence et interface

L'exécution est synchrone et réentrante [SWS_EcuM_04122]. Le service est déclaré via le fichier d'en-tête EcuM.h [SWS_EcuM_04122].

Utilisation

La fonction synchrone et réentrante EcuM_RequestRUN sert à demander l'état RUN auprès de l'ECU State Manager [SWS_EcuM_04124]. L'identifiant de l'entité demandeuse est transmis via le paramètre user de type EcuM_UserType ; seuls sont autorisés les utilisateurs qui ont déjà été portés à la connaissance du gestionnaire d'état au moment de la configuration [SWS_EcuM_04124]. La fonction renvoie E_OK lorsque l'EcuM a accepté la demande, sinon E_NOT_OK [SWS_EcuM_04124]. Le service est déclaré via l'en-tête EcuM.h [SWS_EcuM_04124].

Traitement des erreurs et restrictions

Les demandes ne doivent pas être imbriquées : un utilisateur individuel ne peut détenir au maximum qu'une seule demande RUN active à un instant donné [SWS_EcuM_04125]. Si EcuM_RequestRUN détecte des appels répétés ou en double par le même utilisateur, le code d'erreur ECUM_E_MULTIPLE_RUN_REQUESTS est signalé au DET lorsque la détection des erreurs de développement est activée [SWS_EcuM_03024], [SWS_EcuM_04125].

Interaction

Chaque demande d'état définie avec succès par EcuM_RequestRUN doit être à nouveau libérée une fois l'activité terminée. Le service complémentaire EcuM_ReleaseRUN, également synchrone et réentrant, auquel est transmis le même identifiant utilisateur, est disponible à cet effet [SWS_EcuM_04127].

Utilisation

La fonction synchrone EcuM_ReleaseRUN (ID de service 0x04) sert à libérer une demande d'état RUN précédemment enregistrée via EcuM_RequestRUN [SWS_EcuM_04127]. L'interface est fournie via l'en-tête EcuM.h et est principalement prévue pour l'implémentation de ports AUTOSAR [SWS_EcuM_04127]. Comme paramètre d'entrée, la fonction attend l'identifiant utilisateur user de type EcuM_UserType, qui identifie de manière unique l'entité effectuant la libération au sein du module [SWS_EcuM_04127].

La valeur de retour de type Std_ReturnType signale par E_OK que la demande de libération a été acceptée avec succès par le module [SWS_EcuM_04127]. Si la libération n'a pas pu être traitée, le service renvoie la valeur d'erreur E_NOT_OK [SWS_EcuM_04127].

Gestion des erreurs et concurrence

Aucun code d'erreur spécifique, erreur de développement (DET) ou erreur de production (DEM) n'est mentionné dans la spécification ; le rejet d'une demande se manifeste exclusivement par le renvoi de E_NOT_OK [SWS_EcuM_04127]. Il est à supposer (interprétation :) qu'un renvoi de E_NOT_OK se produit vraisemblablement lorsqu'aucune demande active n'existe pour l'ID utilisateur indiqué ou qu'une valeur de paramètre non autorisée a été transmise. Question Q-cbe9031cffe1be81 (ouverte)

La fonction est déclarée comme réentrante et peut donc être appelée dans des contextes d'exécution concurrents [SWS_EcuM_04127]. Comme condition préalable d'ordonnancement fonctionnel, l'appel exige impérativement que l'utilisateur correspondant ait préalablement demandé l'état via EcuM_RequestRUN [SWS_EcuM_04127].

Interaction

Le module EcuM fournit ce service pour mettre fin au maintien de l'état RUN via des ports définis [SWS_EcuM_04127]. Pour la configuration RTE et l'interaction avec le comportement temporel RTE local, la spécification définit le comportement interne de l'EcuStateManager avec plusieurs Runnable Entities exécutables de manière concurrente [SWS_EcuM_03018].

Utilisation

La fonction synchrone EcuM_RequestPOST_RUN sert à demander l'état POST RUN auprès de l'ECU State Manager ([SWS_EcuM_04128]). L'appelant s'identifie via le paramètre user, chaque entité demandeuse devant déjà avoir été portée à la connaissance du gestionnaire d'état au moment de la configuration ([SWS_EcuM_04128]). Le service est déclaré dans l'en-tête EcuM.h, prévu pour l'implémentation de ports AUTOSAR et acquitte une acceptation réussie par E_OK ou un rejet par E_NOT_OK ([SWS_EcuM_04128]).

Gestion des erreurs

Si la détection des erreurs de développement est activée, un nouvel appel par le même utilisateur conduit EcuM_RequestPOST_RUN à signaler l'erreur ECUM_E_MULTIPLE_RUN_REQUESTS au DET ([SWS_EcuM_03025]). Interprétation : dans le cas de telles demandes multiples ou en présence d'identifiants utilisateur non valides, le service devrait répondre par E_NOT_OK ([SWS_EcuM_04128]). Question Q-b5bbd7d5b53e76ba (ouverte)

Concurrence et interaction

La fonction est conçue pour être réentrante ([SWS_EcuM_04128]). Dans le module, les requêtes pour RUN et POST RUN doivent être tracées de manière strictement indépendante l'une de l'autre via deux variables distinctes ([SWS_EcuM_04128]). Chaque requête enregistrée via ce service maintient l'état POST RUN actif jusqu'à ce qu'elle soit explicitement annulée par l'appel complémentaire de EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]).

Utilisation et sémantique

La fonction synchrone et réentrante EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) sert à libérer une demande de POST-RUN précédemment définie au moyen de EcuM_RequestPOST_RUN. L'identifiant de l'entité qui libère l'état POST-RUN est transmis via le paramètre d'entrée user de type EcuM_UserType. L'interface est disponible via le fichier d'en-tête EcuM.h et est principalement conçue pour la réalisation de ports AUTOSAR ([SWS_EcuM_04129]).

Valeurs de retour et gestion des erreurs

La fonction renvoie l'état Std_ReturnType ([SWS_EcuM_04129]) :

• E_OK : la demande de libération a été acceptée avec succès par l'ECU State Manager.
• E_NOT_OK : la demande de libération a été rejetée. Interprétation : un rejet avec E_NOT_OK devrait se produire si aucune demande active n'était enregistrée pour l'utilisateur indiqué ou si un identifiant d'utilisateur invalide a été transmis. Question Q-67bd8594612defca (ouverte)

Concurrence et interaction

Le service est spécifié comme réentrant ([SWS_EcuM_04129]), de sorte que des appels simultanés par plusieurs entités sont autorisés. La fonction fait partie du comportement interne du module EcuM ([SWS_EcuM_03018]). L'appel suppose logiquement que l'entité a préalablement demandé la phase POST RUN ([SWS_EcuM_04129]). Interprétation : typiquement, l'appel devrait provenir de composants logiciels via des ports RTE dès que leurs activités de post-fonctionnement avant la coupure sont terminées. Question Q-81f71656d4debb4a (ouverte)

La fonction de service synchrone EcuM_SelectShutdownTarget sert à sélectionner la cible d'arrêt pour le calculateur et est mise à disposition via le fichier d'en-tête EcuM.h ainsi qu'en tant que partie de l'interface de port du module ECU Manager [SWS_EcuM_02822]. Par cet appel, la cible d'arrêt interne est définie sur la valeur du paramètre transmis shutdownTarget [SWS_EcuM_00624].

La fonction attend deux paramètres d'entrée [SWS_EcuM_02822] :

• shutdownTarget : détermine la cible sélectionnée pour l'arrêt [SWS_EcuM_02822].
• shutdownMode : contient l'identifiant d'un mode veille (lorsque la cible est ECUM_SHUTDOWN_TARGET_SLEEP) ou d'un mécanisme de réinitialisation (lorsque la cible est ECUM_SHUTDOWN_TARGET_RESET) selon la configuration [SWS_EcuM_02822].

L'appel ne déclenche aucune activité immédiate de configuration ou d'exécution (setup), mais enregistre uniquement les valeurs pour une utilisation ultérieure dans la phase SHUTDOWN ou SLEEP [SWS_EcuM_02585].

Concernant la concurrence, la fonction est spécifiée comme réentrante [SWS_EcuM_02822]. Dans l'Internal Behavior RTE de l'ECU State Manager, l'entité exécutable correspondante SelectShutdownTarget est déclarée avec canbeInvokedConcurrently = TRUE [SWS_EcuM_03018], ce qui autorise les appels parallèles.

La valeur de retour de type Std_ReturnType signale par E_OK que la nouvelle cible d'arrêt a été définie avec succès, et par E_NOT_OK que la prise en compte a échoué [SWS_EcuM_02822]. La spécification ne mentionne pas ici de causes d'erreur concrètes pour E_NOT_OK ou de messages DET ; des combinaisons non autorisées ou non configurées de cible et de mode conduisent vraisemblablement à un rejet. Question Q-e916f3a6ac0bf47e (ouverte)

La fonction synchrone EcuM_SelectShutdownCause sert à sélectionner la cause d'un arrêt du calculateur et est disponible via le fichier d'en-tête EcuM.h [SWS_EcuM_04050].

Utilisation et sémantique :

• Paramètres : le paramètre d'entrée target de type EcuM_ShutdownCauseType transmet la cause d'arrêt sélectionnée [SWS_EcuM_04050].
• Valeur de retour : une valeur de retour de type Std_ReturnType signale avec E_OK que la nouvelle cause a été définie avec succès, et avec E_NOT_OK que la définition a échoué [SWS_EcuM_04050].
• Exécution : le service fonctionne de manière synchrone sous le Service-ID 0x1b et est spécifié comme réentrant [SWS_EcuM_04050].

Concurrence et interaction :

La fonction fait partie de l'interface de port du module ECU Manager [SWS_EcuM_04050]. Pour la configuration de la RTE locale, la Runnable Entity SelectShutdownCause est définie avec le symbole EcuM_SelectShutdownCause dans le comportement interne EcuStateManager, la propriété canbeInvokedConcurrently = TRUE étant attribuée [SWS_EcuM_03018].

Traitement des erreurs :

Aucun message DET ou DEM spécifique n'est indiqué dans le périmètre de la spécification ; les états d'erreur lors de la définition de la cause sont signalés exclusivement via la valeur de retour E_NOT_OK [SWS_EcuM_04050].

La fonction de service synchrone EcuM_ClearWakeupEvent (ID de service 0x16) sert à réinitialiser les événements de réveil et est disponible via le fichier d'en-tête EcuM.h [SWS_EcuM_02828]. Comme paramètre, elle prend le masque de bits sources de type EcuM_WakeupSourceType et ne possède pas de valeur de retour [SWS_EcuM_02828].

Lors de l'appel, tous les événements en attente définis sous forme de bit dans sources sont supprimés de trois variables internes du module [SWS_EcuM_02683] :

• de la variable interne pour les événements de réveil en attente (pending wakeup events),
• de la variable interne pour les événements de réveil validés (validated events) ainsi que
• de la variable interne pour les événements de réveil expirés (expired events) [SWS_EcuM_02683].

En ce qui concerne le contexte d'appel, EcuM_ClearWakeupEvent peut être appelée de manière flexible depuis le contexte d'interruption, depuis le contexte régulier d'OS ainsi que depuis un contexte sans OS [SWS_EcuM_02807]. En même temps, la fonction est toutefois obligatoirement spécifiée comme non réentrante (Non-Reentrant) et non interruptible (Non-Interruptible) [SWS_EcuM_02828]. Interprétation : comme la fonction est admissible dans différents contextes mais n'est pas interruptible, l'intégrateur ou l'appelant devrait devoir s'assurer sur le plan organisationnel qu'aucun appel simultané ou s'interrompant mutuellement n'a lieu. Question Q-71a4b1b218505a1c (ouverte)

La fonction synchrone EcuM_AbortWakeupAlarm sert à l'annulation d'une alarme de réveil préalablement définie par un utilisateur [SWS_EcuM_04061]. L'interface est disponible via le fichier d'en-tête EcuM.h et constitue un composant de l'interface de port du module ECU Manager [SWS_EcuM_04061].

Paramètres et valeurs de retour

• user (In) : identifiant de l'utilisateur de type EcuM_UserType souhaitant annuler l'alarme de réveil [SWS_EcuM_04061]. Il n'existe aucun paramètre d'entrée/sortie ou de sortie pure [SWS_EcuM_04061].
• E_OK : le service a été exécuté avec succès et l'alarme a été annulée [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE : aucune alarme active appartenant à l'utilisateur transmis n'a été trouvée [SWS_EcuM_04061].
• E_NOT_OK : l'exécution du service a échoué [SWS_EcuM_04061].

Concurrence et interaction

La fonction possède l'ID de service 0x24 et est spécifiée comme réentrante [SWS_EcuM_04061]. Les appels peuvent ainsi avoir lieu de manière concurrente pour différents utilisateurs. Le comportement interne de l'ECU Manager définit les entités exécutables pour la configuration de la RTE locale [SWS_EcuM_03018] ; en tant que partie de l'interface de port du module, l'appel devrait typiquement être initié par des composants logiciels via la RTE. Question Q-2c8f004d9f00bbd3 (ouverte)

La fonction synchrone et réentrante EcuM_SetClock sert, selon [SWS_EcuM_04064], à définir l'heure interne de l'ECU State Manager à une valeur prédéfinie. Faisant partie de l'interface de port de l'ECU Manager, la fonction peut être intégrée et appelée via le fichier d'en-tête EcuM.h [SWS_EcuM_04064].

L'objectif principal de l'interface est le test des services d'alarme : les alarmes dont le déroulement régulier nécessiterait des jours peuvent être vérifiées en mode test en définissant de manière ciblée l'heure [SWS_EcuM_04064]. Deux paramètres d'entrée sont ici transmis :

• user (type EcuM_UserType) : identifiant de l'appelant ou de l'utilisateur souhaitant définir l'heure.
• time (type EcuM_TimeType) : indication horaire absolue en secondes depuis le raccordement de la batterie (Battery Connect).

En tant que valeur de retour, le service renvoie le statut Std_ReturnType avec E_OK en cas d'exécution réussie ou E_NOT_OK en cas d'erreur [SWS_EcuM_04064]. Aucune cause d'erreur concrète ni aucun message DET ne sont spécifiés sur l'interface ; la transmission d'identifiants utilisateur non autorisés ou de valeurs temporelles non valides conduit vraisemblablement au renvoi de E_NOT_OK. Question Q-248768580c0309e8 (ouverte)

Concernant le comportement interne du module et la configuration de la RTE, la fonction s'intègre dans la structure des Runnable Entities de l'EcuStateManager [SWS_EcuM_03018].

La fonction synchrone EcuM_SelectBootTarget sert à sélectionner une cible de démarrage pour le calculateur et fait partie de l'interface de port de l'ECU Manager, tout en étant disponible via l'en-tête EcuM.h [SWS_EcuM_02835]. La cible souhaitée est transmise via le paramètre d'entrée target de type EcuM_BootTargetType [SWS_EcuM_02835].

Comme valeur de retour, la fonction signale E_OK lorsque la nouvelle cible de démarrage a été acceptée par l'EcuM, et sinon E_NOT_OK [SWS_EcuM_02835]. L'implémentation doit enregistrer la cible sélectionnée d'une manière compatible avec le bootloader [SWS_EcuM_02247]. La valeur actuellement définie peut être interrogée via le service complémentaire EcuM_GetBootTarget [SWS_EcuM_02836].

La fonction est spécifiée comme réentrante [SWS_EcuM_02835] ; dans le cadre du comportement interne pour la configuration RTE, l'entité exécutable (Runnable Entity) SelectBootTarget est déclarée avec canbeInvokedConcurrently = TRUE [SWS_EcuM_03018]. À titre restrictif, ce service est exclusivement prévu pour les composants logiciels (SW-Cs) en lien avec le diagnostic ou la gestion du démarrage, et peut dépendre du bootloader concrètement utilisé [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent est un service synchrone (ID de service 0x14) qui signale à l'ECU Manager que les sources de réveil transmises dans le paramètre sources ont été validées avec succès ([SWS_EcuM_02829]). Après le réveil, l'ECU State Manager attend cette confirmation dans la séquence de validation. Lors de l'appel, la fonction arrête le temporisateur d'expiration de la validation en cours ([SWS_EcuM_02710]) et inscrit les événements transmis dans la variable interne pour les événements de réveil validés par une opération OU logique sur le masque de bits ([SWS_EcuM_04078]).

La fonction est réentrante ([SWS_EcuM_02829]) et peut être appelée aussi bien depuis le contexte de tâche que depuis le contexte d'interruption ([SWS_EcuM_02345]). Si l'ECU Manager se trouve dans l'état RUN, l'appel reste sans effet pour toutes les sources de réveil, tant qu'il ne s'agit pas de canaux de communication ([SWS_EcuM_02790]). En revanche, pour les sources associées à un canal de communication, le service déploie un effet sans restriction à chaque phase de l'ECU ([SWS_EcuM_02791]).

Dans le déroulement global, le service interagit étroitement avec la validation de réveil et la gestion de la communication :

• Contrôle de validation : l'ECU Manager appelle le callout EcuM_CheckValidation pour vérification ; si un événement de réveil valide est détecté, le retour s'effectue via EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Configuration : si aucun protocole de validation n'est configuré pour une source de réveil (EcuMValidationTimeout), EcuM_SetWakeupEvent implique déjà l'appel de EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Notification : si EcuMComMChannelRef est configuré pour la source de réveil, le service appelle ComM_EcuM_WakeUpIndication ([SWS_EcuM_02645]). Si EcuMComMPNCRef est configuré, ComM_EcuM_PNCWakeUpIndication est en plus déclenché pour chaque PNC référencé ([SWS_EcuM_04140]).

La fonction de rappel synchrone et non réentrante EcuM_ErrorHook (fournie via EcuM_Externals.h) est appelée par l'ECU State Manager dès que surviennent des erreurs graves qui rendent tout traitement ultérieur régulier impossible et nécessitent l'arrêt du calculateur [SWS_EcuM_02904]. La cause d'erreur spécifique est transmise via le paramètre de transmission reason [SWS_EcuM_02904].

Parmi les causes d'erreur définies figurent ECUM_E_RAM_CHECK_FAILED et ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. Si le contrôle de la RAM échoue lors du réveil, l'ECU Manager est tenu de déclencher EcuM_ErrorHook avec la raison ECUM_E_RAM_CHECK_FAILED [SWS_EcuM_02987]. De plus, le traitement des erreurs s'effectue via ce hook lorsqu'un appel d'une fonction du système d'exploitation échoue et qu'aucune autre réaction à l'erreur n'est spécifiée ; l'EcuM demeure dans ce cas dans son état précédent [SWS_EcuM_04139].

Pour l'intégrateur système, les conditions-cadres suivantes s'appliquent lors de l'implémentation :

• Modalité d'arrêt du calculateur : l'intégrateur choisit la manière dont l'ECU est mise à l'arrêt (par ex. réinitialisation, arrêt/halt, redémarrage ou état sûr) [SWS_EcuM_02904]. Interprétation : lors de mesures drastiques telles qu'une réinitialisation ou un arrêt, la fonction ne devrait généralement plus retourner au contrôle d'exécution régulier. Question Q-59c23e3a2569f670 (ouverte)
• Notification d'erreur au DEM : il est à la discrétion de l'intégrateur de transmettre ou non l'erreur au DEM, pourvu qu'il soit garanti que le DEM n'écrive pas dans des blocs de NVRAM corrompus [SWS_EcuM_02987].

Utilisation et conditions d'appel

La fonction de callout EcuM_AL_SetProgrammableInterrupts est appelée par le module ECU State Manager afin de configurer et de définir les interruptions correspondantes sur les calculateurs équipés de contrôleurs d’interruptions programmables [SWS_EcuM_04085]. Toutefois, l’exécution de ce callout n’a lieu que si le paramètre de configuration EcuMSetProgrammableInterrupts est fixé à la valeur true [SWS_EcuM_04085]. Si ce paramètre n’est pas activé, l’appel n’est pas effectué [SWS_EcuM_04085]. Pour les intégrateurs et les pilotes de plateforme, la déclaration de l’interface est mise à disposition via le fichier d’en-tête EcuM_Externals.h [SWS_EcuM_04085].

L’interface possède la syntaxe void EcuM_AL_SetProgrammableInterrupts (void) et est associée au Service-ID 0x4A [SWS_EcuM_04085]. L’appel s’effectue de manière totalement sans paramètres : aucun paramètre d’entrée, d’entrée/sortie ou de sortie n’est transmis, et la fonction ne renvoie aucune valeur de retour au module appelant [SWS_EcuM_04085].

Concurrence et restrictions

Pour EcuM_AL_SetProgrammableInterrupts, un comportement d'exécution asynchrone (Asynchronous) est défini dans la spécification [SWS_EcuM_04085]. En ce qui concerne la concurrence, la fonction est classée comme non réentrante (Non Reentrant) [SWS_EcuM_04085]. Pour l'intégration, cela signifie que les appels parallèles ou imbriqués de l'interface ne sont pas autorisés et que la configuration liée aux interruptions doit se dérouler sans réentrances simultanées [SWS_EcuM_04085].

Utilisation

La fonction de callout EcuM_AL_DriverInitZero (ID de service 0x31) est appelée de manière synchrone, ne possède ni paramètres ni valeur de retour et n'est pas réentrante [SWS_EcuM_02905]. Elle est déclarée via l'en-tête EcuM_Externals.h [SWS_EcuM_02905]. La fonction sert à fournir des initialisations de pilotes précoces ainsi que des activités de démarrage fondamentales liées au matériel, impérativement nécessaires pour pouvoir charger ultérieurement les données de configuration post-build [SWS_EcuM_02905].

Restrictions et fonctionnement multicœur

Des consignes et restrictions spécifiques s'appliquent à l'implémentation et à l'exécution :

• Classes de configuration : à ce stade précoce, seuls les modules configurables en pre-compile ou en link-time peuvent être utilisés [SWS_EcuM_02905]. Les pilotes configurables en post-build ne sont pas encore disponibles ici.
• Contexte d'appel : la fonction est appelée par EcuM_Init sur chaque Core du système [SWS_EcuM_04145].
• Initialisation spécifique au Core : l'implémentation du callout doit garantir que, sur le Core actuellement actif, seuls les modules MCAL effectivement exécutés sur ce Core spécifique sont initialisés [SWS_EcuM_04145].

Aucune valeur de retour, aucun code d'erreur spécifique ni aucune notification via DET ou DEM ne sont définis pour ce callout [SWS_EcuM_02905].

La fonction EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) est un callout synchrone de l'ECU State Manager, mis à disposition via le fichier d'en-tête EcuM_Externals.h et doté du Service-ID 0x32. L'interface ne possède aucun paramètre d'entrée, de sortie ou d'entrée/sortie ([SWS_EcuM_02906]). Son objectif central consiste à définir, pendant le processus de démarrage, sur la base de conditions matérielles ou de mémoire, quel ensemble de données de configuration post-build doit être retenu pour la suite du démarrage du système ([SWS_EcuM_02906]).

Pour définir la configuration, le callout doit évaluer des critères externes ou résidents tels que l'état d'une broche de port ou une valeur dans la NVRAM ([SWS_EcuM_02906]). Ensuite, la fonction doit charger ces données de configuration dans un segment de mémoire auquel l'ensemble des modules BSW peuvent accéder ([SWS_EcuM_02906]). En tant que valeur de retour, elle renvoie un pointeur de type const EcuM_ConfigType* vers la configuration post-build de l'EcuM ([SWS_EcuM_02906]). Ce pointeur constitue la base de départ commune pour toute la BSW, car la structure contient des pointeurs vers les configurations post-build respectives de tous les autres modules BSW ([SWS_EcuM_02906]).

Concernant le comportement d'appel, la fonction est spécifiée comme synchrone et non réentrante (Non Reentrant) ([SWS_EcuM_02906]). Aucun code d'erreur spécifique, valeur de retour d'erreur particulière ou interface vers DET ou DEM n'est défini pour ce callout ([SWS_EcuM_02906]). Il convient donc de considérer comme une interprétation des exigences qu'une implémentation de callout spécifique à l'application doit gérer les états d'erreur de manière autonome, étant donné que l'absence d'un pointeur de configuration valide empêcherait probablement le démarrage ordonné des modules BSW dépendants. Question Q-b9487647fb39a2e2 (ouverte)

Utilisation et sémantique

La fonction EcuM_AL_DriverInitOne est une fonction de callout de l'ECU State Manager (EcuM), mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02907]. Sa tâche principale consiste à effectuer, en cas de réinitialisation à la mise sous tension, l'initialisation des pilotes ainsi que d'autres activités de démarrage de l'unité de commande liées au matériel [SWS_EcuM_02907]. Comme il s'agit d'un callout, l'implémentation concrète de l'initialisation du matériel et des pilotes devrait être réalisée par l'intégrateur système respectif. Question Q-e22baf2fa31cf075 (ouverte)

L'interface possède la signature C void EcuM_AL_DriverInitOne (void) et est associée à l'ID de service 0x33 [SWS_EcuM_02907]. Elle n'accepte aucun paramètre d'entrée et ne renvoie aucune valeur de retour à l'appelant [SWS_EcuM_02907].

Concurrence et restrictions

Pour l'appel et le comportement à l'exécution, les conditions limites suivantes s'appliquent selon [SWS_EcuM_02907] :

• Synchronicité : l'exécution s'effectue de manière synchrone (Synchronous), de sorte que l'appelant attend l'achèvement des activités de démarrage.
• Réentrance : la fonction est définie comme non réentrante (Non Reentrant) ; un appel multiple simultané ou interruptif n'est pas autorisé.
• Contexte d'appel : l'activation est spécifiée exclusivement pour la phase d'initialisation survenant immédiatement après une réinitialisation à la mise sous tension.

Gestion des erreurs

Comme EcuM_AL_DriverInitOne présente le type de retour void, il n'existe au niveau de l'interface aucun retour d'information direct quant au succès ou à l'erreur de l'initialisation [SWS_EcuM_02907]. Les codes d'erreur spécifiques ainsi que les messages DET ou DEM ne sont pas définis pour ce callout dans le cadre de la présente spécification.

La fonction EcuM_LoopDetection est un callout de l'ECU State Manager avec l'ID de service 0x4B, mis à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_04137].

Utilisation et contexte d'appel

Si le paramètre de configuration EcuMResetLoopDetection est défini sur true, ce callout est appelé de manière synchrone lors de chaque démarrage (Startup) [SWS_EcuM_04137]. La fonction ne possède aucun paramètre d'entrée, d'entrée/sortie ou de sortie et ne renvoie aucune valeur de retour (signature : void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Concurrence et restrictions

L'exécution de EcuM_LoopDetection est spécifiée comme synchrone et non réentrante (Non Reentrant) [SWS_EcuM_04137]. Comme il s'agit d'un callout, l'implémentation concrète de la détection de boucle incombe généralement à l'intégrateur ou à l'utilisateur, afin de détecter des boucles de reset répétées lors du démarrage du système.

Utilisation

La fonction EcuM_OnGoOffOne sert à annoncer que l’état du système GO OFF I est atteint et à donner au concepteur du système la possibilité de prendre les mesures appropriées immédiatement avant la transition [SWS_EcuM_02916]. La fonction est exécutée de manière synchrone, n’attend aucun paramètre de transmission (ni in ni inout) et ne renvoie aucune valeur de retour (void) [SWS_EcuM_02916]. Comme l’interface est déclarée via le fichier d’en-tête EcuM_Externals.h, il s’agit vraisemblablement d’une fonction de callout spécifique à l’utilisateur, implémentée dans le code d’intégration [SWS_EcuM_02916]. Question Q-93de53c47a5a6142 (ouverte)

Gestion des erreurs

Dans la spécification relative à EcuM_OnGoOffOne, ni erreurs de développement (DET), ni erreurs de production (DEM), ni valeurs de retour d’erreur spécifiques ne sont indiquées [SWS_EcuM_02916]. Il en ressort que l’appelant n’attend aucune gestion d’erreur standardisée et que les éventuels cas d’exception doivent être traités de manière autonome au sein de l’implémentation spécifique à l’utilisateur [SWS_EcuM_02916].

Concurrence et restrictions

Pour le contexte d’appel et le comportement à l’exécution, les propriétés suivantes sont définies [SWS_EcuM_02916] :

• Réentrance : la fonction est spécifiée comme non réentrante (Non Reentrant) et ne doit en aucun cas être appelée en parallèle ou de façon imbriquée [SWS_EcuM_02916].
• Synchronicité : la sémantique est strictement synchrone (Synchronous), de sorte que l’appelant attend le retour complet de la fonction [SWS_EcuM_02916].
• Service-ID : le service est représenté en interne par l’identifiant hexadécimal 0x3C [SWS_EcuM_02916].

En raison du comportement synchrone et de la transition imminente vers l’état GO OFF I, il convient de supposer que les opérations bloquantes doivent être évitées afin de ne pas retarder indûment le processus d’arrêt ou de transition [SWS_EcuM_02916]. Question Q-93f5e23c581f0c38 (ouverte)

La fonction synchrone EcuM_OnGoOffTwo sert, selon la spécification, à permettre la notification du concepteur système du fait que l'état GO OFF II est imminent [SWS_EcuM_02917]. L'appel s'effectue sans paramètre, sans paramètre In, Inout ou Out, et ne renvoie aucune valeur de retour à l'appelant [SWS_EcuM_02917].

En ce qui concerne le contexte d'exécution et la concurrence, l'interface est pourvue de l'ID de service 0x3D et est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02917]. Elle est mise à disposition via l'en-tête EcuM_Externals.h [SWS_EcuM_02917]. Interprétation : comme la déclaration se trouve dans EcuM_Externals.h et sert à la notification du concepteur système, la fonction devrait être conçue comme un callout synchrone de la gestion du calculateur, appelé avant la transition vers l'état GO OFF II. Question Q-bb0ae6e4632de827 (ouverte)

En raison de sa propriété d'interface non réentrante, l'appel ne doit pas être répété de manière parallèle ou interruptive [SWS_EcuM_02917]. Les codes d'erreur spécifiques, les retours vers DET ou DEM ainsi que les mécanismes de traitement d'erreurs distincts ne sont pas définis dans le périmètre de la spécification [SWS_EcuM_02917].

Utilisation

La fonction de callout EcuM_AL_SwitchOff fait partie du module ECU State Manager (EcuM) et sert à accueillir le code spécifique à l'utilisateur pour la coupure de l'alimentation électrique du calculateur [SWS_EcuM_02920]. L'interface est définie comme synchrone, possède l'ID de service 0x3E et est mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02920].

Conformément à la spécification, la fonction ne prend aucun paramètre d'entrée, d'entrée/sortie ou de sortie et ne possède pas de valeur de retour (void) [SWS_EcuM_02920]. Si le matériel du calculateur ne peut pas se mettre hors tension de manière autonome, la spécification prévoit que le déclenchement d'une réinitialisation peut constituer une réaction adéquate à la place [SWS_EcuM_02920].

Interaction et concurrence

L'appel de EcuM_AL_SwitchOff est impérativement effectué par le module ECU Manager dès que la cible d'arrêt choisie est OFF [SWS_EcuM_04075]. En ce qui concerne le comportement face à la concurrence, le callout est défini comme non réentrant (Non Reentrant) [SWS_EcuM_02920]. Interprétation : comme l'objectif de la fonction est la coupure complète de l'alimentation électrique ou, à défaut, une réinitialisation, ce callout devrait représenter l'étape finale de la séquence d'arrêt, après laquelle plus aucune exécution normale du programme n'a lieu. Question Q-e8a1aaa1413bbea9 (ouverte)

Gestion des erreurs

Pour ce callout, aucun code d'erreur spécifique, ni mécanisme de traitement des erreurs, ni message vers DET ou DEM ne sont prévus dans la spécification [SWS_EcuM_02920].

Le callout EcuM_AL_Reset sert à accueillir le code spécifique à l'intégration chargé de réinitialiser le calculateur ([SWS_EcuM_04065]). L'interface est déclarée via le fichier d'en-tête EcuM_Externals.h et possède l'ID de service 0x4C ([SWS_EcuM_04065]).

L'appel de la fonction s'effectue de manière synchrone et est défini comme non réentrant (Non Reentrant) ([SWS_EcuM_04065]). L'unique paramètre d'entrée transmis est reset de type EcuM_ResetType, qui détermine le type concret de reset à exécuter ([SWS_EcuM_04065]). La fonction ne possède pas de valeur de retour (void) et ne comporte aucun paramètre de sortie ou d'entrée/sortie ([SWS_EcuM_04065]).

Dans l'interaction de la phase d'arrêt, il est établi que le module ECU Manager doit obligatoirement appeler le callout EcuM_AL_Reset lorsque la cible de l'arrêt est définie sur RESET ([SWS_EcuM_04074]). Pour le callout, la spécification ne prévoit ni codes d'erreur ni notifications à DET ou DEM ([SWS_EcuM_04065]). Interprétation : le callout devrait exécuter des commandes de contrôle proches du matériel provoquant directement la réinitialisation de la MCU. Question Q-1e318404843faabd (ouverte)

La fonction EcuM_EnableWakeupSources est un callout synchrone de l'ECU Manager doté de l'ID de service 0x3F, déclaré via l'en-tête EcuM_Externals.h [SWS_EcuM_02918]. Elle sert à informer le développeur système que l'état SLEEP est imminent, afin que les sources de réveil indiquées dans le champ de bits wakeupSource (type EcuM_WakeupSourceType) puissent être préparées et configurées en conséquence [SWS_EcuM_02918].

Utilisation et interaction

L'ECU Manager exécute EcuM_EnableWakeupSources afin de configurer les sources de réveil pour le mode veille suivant ; cela s'effectue pour chaque source de réveil configurée dans EcuMWakeupSourceMask pour le mode veille visé [SWS_EcuM_02389]. La fonction ne possède pas de valeur de retour (void) et attend comme paramètre d'entrée le champ de bits wakeupSource [SWS_EcuM_02918].

Concurrence et restrictions

• Réentrance : la fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02918].
• Synchronicité : le traitement s'effectue de manière synchrone [SWS_EcuM_02918].
• Traitement des erreurs : aucun message d'erreur DET ou DEM spécifique n'est défini dans le périmètre de spécification de l'interface [SWS_EcuM_02918].

La fonction EcuM_GenerateRamHash sert à générer une valeur de contrôle de la RAM dans le contexte de l'ECU State Manager, la spécification renvoyant à EcuM_CheckRamHash en ce qui concerne son fonctionnement [SWS_EcuM_02919]. La valeur de contrôle générée sert probablement à la vérification ultérieure de l'intégrité de la mémoire vive en relation avec des états de veille ou de repos. Question Q-7f316b389e1609c0 (ouverte)

Utilisation et interface

Le service possède l'ID de service 0x40 et la signature void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. La fonction ne possède ni paramètre d'entrée, de sortie ou d'entrée/sortie, et ne fournit aucune valeur de retour. L'exécution s'effectue de manière synchrone.

Concurrence et restrictions

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02919]. Elle ne doit par conséquent pas être appelée de manière interruptive ou parallèle à partir de plusieurs contextes. La déclaration est mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02919]. Interprétation : du fait de sa définition dans EcuM_Externals.h, il devrait s'agir d'un callout à implémenter de manière spécifique à l'utilisateur, appelé par l'ECU State Manager à un moment approprié du déroulement des états. Question Q-2f53f1a19cee079c (ouverte)

Gestion des erreurs

Pour EcuM_GenerateRamHash, aucun code d'erreur spécifique ni aucun message DET ou DEM ne sont définis dans [SWS_EcuM_02919].

Utilisation et contexte d'appel

La fonction EcuM_SleepActivity constitue un callout de l’ECU State Manager, mis à disposition dans le fichier d’en-tête EcuM_Externals.h avec le Service-ID 0x41 [SWS_EcuM_02928]. L’appel s’effectue périodiquement dans tous les modes de sommeil à fréquence d’horloge processeur réduite (reduced clock sleep modes) [SWS_EcuM_02928]. La fonction possède la signature void EcuM_SleepActivity(void), fonctionne de manière synchrone et n’accepte aucun paramètre d’entrée, de sortie ou d’entrée/sortie [SWS_EcuM_02928].

Tâches fonctionnelles et interaction

L’objectif de ce callout est l’exécution d’activités pendant le sommeil : il est explicitement prévu et autorisé d’interroger périodiquement des sources de réveil (polling) au sein de EcuM_SleepActivity [SWS_EcuM_02928]. De plus, des fonctions de notification de réveil peuvent être appelées directement depuis le callout afin d’indiquer à l’ECU State Manager la fin de l’état de sommeil [SWS_EcuM_02928].

Concurrence et restrictions

L’interface est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02928]. Comme le callout ne renvoie aucune valeur de retour et qu’aucun paramètre d’erreur n’est défini, aucune gestion d’erreur directe n’a lieu via l’interface de fonction au moyen de codes d’erreur ou de mécanismes de signalement d’erreur comme DET ou DEM [SWS_EcuM_02928].

Utilisation et contexte d'appel

L'interface synchrone EcuM_StartCheckWakeup est appelée selon [SWS_EcuM_04096] par le firmware de l'ECU pour démarrer le timer CheckWakeupTimer pour une source de réveil donnée. Le paramètre WakeupSource de type EcuM_WakeupSourceType est transmis à cet effet à la fonction. Elle ne possède pas de valeur de retour (void) et est mise à disposition via le fichier d'en-tête EcuM_Externals.h.

Déroulement et conditions

L'exécution de la fonction dépend de la configuration de la source de réveil [SWS_EcuM_04096] :

• Si EcuMCheckWakeupTimeout > 0 est configuré pour la source de réveil concernée, le CheckWakeupTimer correspondant est démarré.
• Si EcuMCheckWakeupTimeout <= 0 s'applique, l'appel de fonction est entièrement ignoré par l'EcuM.

Concurrence et traitement des erreurs

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_04096]. L'appelant doit par conséquent s'assurer que les appels pour la même source de réveil ou d'autres sources de réveil n'ont pas lieu de manière concurrente. Aucun code d'erreur spécifique ni aucune notification vers DET ou DEM ne sont spécifiés pour cet appel ; un appel avec un timeout non positif reste sans conséquence selon la spécification, ce qui peut vraisemblablement être interprété comme une interception tolérante de vérifications de timer non pertinentes [SWS_EcuM_04096]. Question Q-19d98b03d3ee7504 (ouverte)

Le callout EcuM_CheckWakeup sert à la vérification et au polling des sources de réveil ainsi qu'à la configuration de la PLL après un événement de réveil [SWS_EcuM_02929]. La fonction est mise à disposition via le fichier d'en-tête EcuM_Externals.h et possède l'ID de service 0x42 [SWS_EcuM_02929].

Contexte d'appel et sémantique

• Signature et paramètres : la fonction est exécutée de manière synchrone (Synchronous), ne possède pas de valeur de retour et attend comme paramètre d'entrée wakeupSource de type EcuM_WakeupSourceType [SWS_EcuM_02929].
• Appelants : le callout est appelé par le EcuM pour interroger périodiquement une source de réveil. De plus, il doit impérativement être appelé par la routine de service d'interruption (ISR) d'une source de réveil afin de configurer la PLL et de vérifier d'autres sources de réveil rattachées à la même interruption [SWS_EcuM_02929].
• Boucle de polling : dans la séquence de polling, l'EcuM appelle de manière répétée les callouts EcuM_SleepActivity et EcuM_CheckWakeup dans une boucle bloquante jusqu'à ce qu'un événement de réveil soit signalé comme en attente ou validé [SWS_EcuM_03020].

Restrictions et traitement des erreurs

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02929]. Les appels s'effectuant aussi bien depuis le déroulement bloquant de la séquence de polling que depuis des contextes d'ISR, l'intégration devrait devoir s'assurer qu'aucun appel concurrent non coordonné n'ait lieu. Question Q-8bc8f164670a0911 (ouverte) Aucun code d'erreur spécifique ni notification d'erreur vers DET ou DEM n'est défini pour ce callout.

La fonction synchrone EcuM_EndCheckWakeup est appelée par des modules logiciels lorsque la vérification asynchrone d'une source de réveil (comme par exemple avec un pilote d'émetteur-récepteur CAN asynchrone) donne un résultat négatif, c'est-à-dire qu'aucun événement de réveil n'est présent par cette source [SWS_EcuM_02927].

Utilisation et paramètres

La source de réveil pour laquelle le timer de surveillance associé doit être interrompu est transmise via le paramètre d'entrée WakeupSource de type EcuM_WakeupSourceType [SWS_EcuM_02927]. La fonction ne fournit aucune valeur de retour (void) et ne dispose d'aucun paramètre d'entrée/sortie ou de sortie [SWS_EcuM_02927].

Fonctionnement et concurrence

• La fonction annule le timer CheckWakeupTimer pour la source de réveil spécifiée ; avec l'interruption de ce timer, la vérification de la source de réveil est considérée comme terminée [SWS_EcuM_02927].
• L'interface est définie comme synchrone et non réentrante (Non Reentrant) [SWS_EcuM_02927].
• La déclaration est mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02927].

La fonction EcuM_CheckRamHash est un callout synchrone non réentrant (déclaré dans EcuM_Externals.h) qui fournit un test d'intégrité de la mémoire RAM [SWS_EcuM_02921]. La fonction ne possède aucun paramètre et renvoie une valeur d'état de type uint8 : la valeur 0 signale un échec du test, tandis que toute autre valeur indique une réussite [SWS_EcuM_02921].

Conformément à [SWS_EcuM_02863], le module EcuM appelle d'abord [SWS_EcuM_02919] avant d'arrêter le microcontrôleur, puis exécute EcuM_CheckRamHash après le retour de l'état d'arrêt. L'objectif est de vérifier que le contenu de la RAM est resté cohérent même après une longue phase de SLEEP [SWS_EcuM_02921].

Les conditions limites suivantes s'appliquent à l'implémentation et au déroulement :

• Algorithme et zone de test : la fonction de test est fournie par le concepteur système ; elle ne doit pas nécessairement être exhaustive, mais doit s'exécuter rapidement et détecter les erreurs avec une sûreté suffisante [SWS_EcuM_02921]. Les zones à vérifier doivent être choisies avec soin ; les contenus de pile de la tâche exécutante ne peuvent généralement pas être vérifiés [SWS_EcuM_02921].
• Structure des tâches : il est considéré comme une bonne pratique d'exécuter la génération et la vérification du hachage dans la même tâche non interruptible, avec une activité intermédiaire minimale [SWS_EcuM_02921].
• Multicœur : en présence de plusieurs cœurs de processeur avec des EcuM satellites, le callout est exclusivement appelé par l'EcuM maître et ne vérifie que les données situées dans sa portée [SWS_EcuM_02863], [SWS_EcuM_02921].

Aucun message DET ou DEM spécifique n'est défini pour ce callout ; la réaction à l'erreur en cas de valeur de retour 0 devrait probablement être laissée à la discrétion de la conception système de niveau supérieur [SWS_EcuM_02921]. Question Q-473ef8617db29fe3 (ouverte)

L'interface synchrone EcuM_DisableWakeupSources avec le Service-ID 0x44 sert à configurer les sources de réveil définies dans le paramètre de champ de bits wakeupSource de type EcuM_WakeupSourceType de telle sorte que celles-ci ne puissent plus réveiller le calculateur [SWS_EcuM_02922]. La signature de la fonction est void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

Selon la spécification, les propriétés suivantes s'appliquent au contexte d'appel et à l'intégration :

• Appelant et en-tête : la fonction est appelée par le module ECU Manager et mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02922].
• Paramètres et valeurs de retour : le champ de bits wakeupSource est transmis comme unique paramètre d'entrée. La fonction ne possède aucun paramètre d'entrée/sortie ni de sortie et ne renvoie aucune valeur de retour (void) [SWS_EcuM_02922].
• Sémantique d'exécution et concurrence : le traitement s'effectue de manière synchrone. De plus, la fonction est spécifiée comme non réentrante (Non Reentrant), si bien que les appels simultanés ou imbriqués doivent être évités [SWS_EcuM_02922].

Concernant le traitement des erreurs, la spécification ne contient pour cet appel de fonction ni codes d'erreur spécifiques ni notifications au DET ou au DEM [SWS_EcuM_02922].

Le callout EcuM_AL_DriverRestart est déclaré via le fichier d'en-tête EcuM_Externals.h et possède l'ID de service 0x45 [SWS_EcuM_02923]. La fonction possède la signature void EcuM_AL_DriverRestart (void), n'exige aucun paramètre de transmission et ne renvoie aucune valeur de retour [SWS_EcuM_02923]. L'objet de cette interface est de fournir l'initialisation des pilotes ainsi que d'autres activités liées au matériel pendant la phase de démarrage en cas de réveil (Wakeup Case) [SWS_EcuM_02923].

Des consignes obligatoires s'appliquent à l'intégration et à l'interaction avec le module EcuM :

• Pour la réinitialisation pendant la phase WakeupRestart, l'intégrateur doit intégrer un bloc de redémarrage dans le code d'intégration pour EcuM_AL_DriverRestart, qui utilise la liste configurée EcuMDriverRestartList [SWS_EcuM_02947] [SWS_EcuM_02923].
• La liste EcuMDriverRestartList peut contenir des pilotes qui agissent comme sources de réveil (Wakeup Sources) [SWS_EcuM_02562]. Dans ce cas, EcuM_AL_DriverRestart doit réarmer (re-arm) le mécanisme de déclenchement du callback de détection de réveil (« wakeup detected ») de ces pilotes [SWS_EcuM_02562].

En ce qui concerne le comportement à l'exécution, la fonction est définie comme synchrone et non réentrante [SWS_EcuM_02923]. Comme il s'agit de code d'intégration spécifique à l'application, la spécification ne définit sur cette interface aucun code d'erreur propre ni aucun message standardisé vers DET ou DEM.

La fonction de callout EcuM_StartWakeupSources sert à démarrer et à mettre en service la ou les sources de réveil transmises de manière à les préparer pour l'exécution ultérieure de la validation du réveil (Wakeup Validation) [SWS_EcuM_02924].

Utilisation et contexte d'appel

La fonction est spécifiée comme un appel synchrone avec l'ID de service 0x46, ne possède aucune valeur de retour (void) et est mise à disposition via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02924].

• Paramètre wakeupSource (in) : transmet la source de réveil à démarrer ou un masque de bits de plusieurs sources de réveil de type EcuM_WakeupSourceType à la fonction de callout [SWS_EcuM_02924]. Il n'existe aucun paramètre d'entrée ou de sortie supplémentaire (inout/out) [SWS_EcuM_02924].

Concurrence et restrictions

En ce qui concerne l'environnement d'exécution, EcuM_StartWakeupSources est classifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02924]. Les appelants doivent donc s'assurer que la fonction n'est pas exécutée simultanément depuis des routines de service d'interruption interruptives ou des tâches parallèles.

Interaction et gestion des erreurs

Comme EcuM_StartWakeupSources est déclarée comme callout, l'activation au niveau matériel des sources concernées incombe à l'implémentation spécifique à l'application par l'intégrateur système [SWS_EcuM_02924]. La spécification ne prévoit pour cette interface ni messages d'erreur vers DET ou DEM, ni valeurs de retour d'erreur spécifiques [SWS_EcuM_02924] ; d'éventuels états d'erreur lors du démarrage des sources devraient donc vraisemblablement être interceptés de manière spécifique à l'intégration au sein du callout. Question Q-b595e7175c34a831 (ouverte)

La fonction EcuM_CheckValidation sert d'interface de callout à l'ECU State Manager pour vérifier une source de réveil [SWS_EcuM_02925]. L'EcuM appelle cette fonction afin de déterminer si un événement de réveil détecté est valide [SWS_EcuM_02925].

Utilisation

Le callout possède l'ID de service 0x47 et est fourni via le fichier d'en-tête EcuM_Externals.h [SWS_EcuM_02925]. Le paramètre d'entrée utilisé est wakeupSource de type EcuM_WakeupSourceType, via lequel la source de réveil à valider est identifiée [SWS_EcuM_02925]. La fonction ne fournit aucune valeur de retour (void) et ne possède aucun paramètre de sortie ou d'entrée/sortie [SWS_EcuM_02925]. L'exécution s'effectue de manière synchrone [SWS_EcuM_02925].

Gestion des erreurs

Aucun code d'erreur spécifique, aucune valeur de retour en cas d'erreur ni aucun message vers le DET ou le DEM ne sont définis pour ce callout dans la spécification.

Concurrence et restrictions

Concernant la concurrence, EcuM_CheckValidation est définie comme non réentrante (Non Reentrant) [SWS_EcuM_02925]. Le contexte appelant de l'EcuM doit garantir qu'aucun appel parallèle ou imbriqué n'a lieu pour la même source de réveil ou pour des sources différentes.

Interaction

Si un événement de réveil valide a été détecté lors de l'exécution, celui-ci doit impérativement être notifié en retour à l'EcuM via l'appel de fonction EcuM_ValidateWakeupEvent() [SWS_EcuM_02925]. Interprétation : la logique spécifique au périphérique pour la vérification du matériel ainsi que la décision relative à la validité devraient être intégralement implémentées dans le code d'intégration. Question Q-08061e09b474728d (ouverte)

La fonction de callout EcuM_StopWakeupSources du module EcuM (Classic Platform) sert à arrêter de manière ciblée la ou les sources de réveil transmises après une validation du réveil infructueuse [SWS_EcuM_02926]. La déclaration de cette interface synchrone est disponible via le fichier d'en-tête EcuM_Externals.h et porte l'ID de service 0x48 [SWS_EcuM_02926].

Utilisation et paramètres d'interface :

• Paramètre d'entrée : l'unique paramètre transmis est wakeupSource de type EcuM_WakeupSourceType, qui spécifie la ou les sources de réveil à arrêter [SWS_EcuM_02926].
• Valeur de retour et entrées/sorties : il n'existe ni paramètres d'entrée/sortie (inout) ni paramètres de sortie (out) [SWS_EcuM_02926]. La fonction ne renvoie aucune valeur de retour (void) à l'appelant [SWS_EcuM_02926].
• Comportement d'exécution : le déroulement de la fonction est défini comme synchrone (Synchronous) [SWS_EcuM_02926].

Concurrence et traitement des erreurs :

L'interface est spécifiée comme non réentrante (Non Reentrant) [SWS_EcuM_02926]. Les appels parallèles ne sont donc pas autorisés et doivent être évités par l'appelant. La spécification ne définit pour ce callout ni codes d'erreur spécifiques, ni valeurs de retour, ni notifications au module Default Error Tracer (DET) ou Diagnostic Event Manager (DEM) [SWS_EcuM_02926]. Interprétation : la fonction étant mise à disposition en tant que callout externe via EcuM_Externals.h, la désactivation matérielle du matériel de réveil concerné ainsi que le traitement interne des erreurs incombent à l'implémentation spécifique à l'utilisateur. Question Q-b537c805bed751ab (ouverte)

Utilisation et contexte d'appel

La fonction EcuM_MainFunction possède la signature void EcuM_MainFunction(void) avec le Service-ID 0x18 et est mise à disposition via le fichier d’en-tête SchM_EcuM.h [SWS_EcuM_02837]. Elle n’accepte aucun paramètre et ne renvoie aucune valeur de retour [SWS_EcuM_02837]. Sa tâche consiste à traiter toutes les activités de l’ECU State Manager pendant que le système d’exploitation fonctionne (« OS is up and running ») [SWS_EcuM_02837]. La fonction devrait typiquement être appelée périodiquement par l’ordonnanceur (interprétation : intégration via SchM_EcuM.h). Question Q-ca471f22bdb1f11d (ouverte)

Interaction et tâches

En fonctionnement continu, EcuM_MainFunction prend en charge des tâches de coordination centrales :

• Validation des sources de réveil : dans la mesure où une liste de candidats de sources de réveil est présente après l’achèvement de la séquence WakeupRestart, le module EcuM valide ces candidats au sein de EcuM_MainFunction [SWS_EcuM_02539].
• Expiration du délai d’attente de validation : si le délai d’attente de validation expire pour un événement de réveil en attente, la fonction applique un OU logique pour positionner le bit correspondant dans la variable interne des événements de réveil expirés [SWS_EcuM_04081]. De plus, elle notifie le BSW Management via BswM_EcuM_Current_Wakeup avec un masque binaire EcuM_WakeupSourceType de l’événement et le statut ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Service Alarm Clock : si le service est présent via EcuMAlarmClockPresent, EcuM_MainFunction met à jour l’Alarm Clock Timer [SWS_EcuM_04002].

Restrictions et instances

Une contrainte essentielle pour les architectures multicœurs ou multi-instances stipule que EcuM_MainFunction doit être exécutée dans toutes les instances de l’EcuM [SWS_EcuM_04011].

Le type de données EcuM_RunStatusType est défini comme uint8 et est fourni via l'en-tête EcuM.h ([SWS_EcuM_04120]). Il sert à la représentation formelle de l'état actuel du protocole Run-Request dans l'ECU-Manager et est transmis comme résultat au Basic Software Mode Manager (BswM) ([SWS_EcuM_04120]).

La plage de valeurs autorisée comprend trois états discrets ([SWS_EcuM_04120]) :

• ECUM_RUNSTATUS_UNKNOWN (valeur 0) : représente un état inconnu et sert simultanément de valeur d'initialisation définie (Init Value).
• ECUM_RUNSTATUS_REQUESTED (valeur 1) : caractérise l'état selon lequel l'état RUN a été activement demandé par l'ECU-Manager.
• ECUM_RUNSTATUS_RELEASED (valeur 2) : signale que l'état RUN a été à nouveau libéré par l'ECU-Manager.

Concernant l'interaction, l'exigence [SWS_EcuM_04121] oblige le module ECU-Manager à informer impérativement le BswM de l'état actuel du protocole Run-Request à l'aide des valeurs d'état mentionnées dans EcuM_RunStatusType. Interprétation : étant donné que l'exigence ne mentionne aucune signature de fonction spécifique ni convention d'appel pour le flux de notification, l'information d'état devrait typiquement être transmise au module BswM via une fonction de notification interne ou une interface de rappel (callback). Question Q-e136b90c2edbc29c (ouverte) Aucun code d'erreur spécifique, message DET ou DEM, ni condition particulière de réentrance n'est prévu pour ce type de données élémentaire dans les présentes exigences.

Le type de données EcuM_WakeupStatusType décrit, conformément à [SWS_EcuM_04041], les états possibles d'une source de réveil (Wakeup Source) dans l'ECU State Manager. Le type est dérivé du type de base uint8 et est mis à disposition via l'en-tête EcuM.h [SWS_EcuM_04041].

La plage de valeurs représente le cycle de vie d'un événement de réveil à travers quatre états [SWS_EcuM_04041] :

• ECUM_WKSTATUS_NONE (valeur 0) : aucun événement de réveil en attente n'a été détecté [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (valeur 1) : un événement de réveil a été détecté, mais n'est pas encore validé [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (valeur 2) : l'événement de réveil est valide et a été confirmé avec succès [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (valeur 3) : l'événement de réveil n'a pas été validé à temps et a donc expiré [SWS_EcuM_04041].

Utilisation et interaction : le type sert de représentation d'état centrale pour les sources de réveil. Interprétation : les appelants devraient évaluer cet état dans le cadre d'interrogations de statut afin de déterminer si une source de réveil est activement validée, a déjà signalé un réveil valide ou si la fenêtre temporelle de validation a été dépassée. Question Q-a3f721e8f1753eb1 (ouverte)

Le type EcuM_StateType est un type de données dérivé de uint8, mis à disposition via l'en-tête EcuM.h et représentant les états de fonctionnement de l'ECU State Manager [SWS_EcuM_91005]. Le module EcuM est tenu de définir l'ensemble des états listés dans EcuM_StateType [SWS_EcuM_02664]. La plage de valeurs comprend le masque de sous-état ECUM_SUBSTATE_MASK (0x0f) ainsi que les états principaux ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40) et ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Utilisation et interaction

Le type de données sert de paramètre central pour la communication d'état entre le BswM et l'EcuM :

• Changement d'état vers l'EcuM : le BswM notifie le module EcuM d'un changement d'état via l'appel de fonction synchrone et réentrant EcuM_SetState(EcuM_StateType state) avec l'ID de service 0x2b [SWS_EcuM_04122].
• Notification d'état au BswM : l'EcuM notifie l'état actuel au BswM en appelant l'interface BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Concurrence, séquencement et traitement des erreurs

En ce qui concerne le séquencement temporel, il est prescrit qu'un nouvel état ne peut être défini par l'EcuM que lorsque la RTE a délivré son acquittement via le port d'acquittement correspondant [SWS_EcuM_04143]. Aucun code d'erreur, valeur de retour ou notification DET/DEM spécifique n'est prévu pour ce type de données dans les sources disponibles.

Le type EcuM_Mode est défini comme ModeDeclarationGroup selon [SWS_EcuM_04107] et représente les états centraux de l'ECU State Manager. Le mode initial défini est STARTUP. De plus, le groupe comprend les modes définis POST_RUN, RUN, SHUTDOWN ainsi que SLEEP [SWS_EcuM_04107].

Dans l'ensemble du système, EcuM_Mode sert de base de type pour le groupe de modes currentMode au sein de l'interface de service EcuM_CurrentMode [SWS_EcuM_04108]. Via cette interface, le mode ECU actuel peut être interrogé ou signalé à d'autres composants logiciels par le mécanisme de mode de la RTE.

En ce qui concerne le contexte d'appel et la concurrence, la spécification du type lui-même ne contient aucune restriction explicite relative à la réentrance ou aux codes d'erreur ; la gestion des transitions d'état s'effectue via les interfaces de service associées de l'EcuM.

L'élément currentMode est défini comme un port fourni (Provided-Port) du module EcuM et met l'interface de service EcuM_CurrentMode à disposition de l'architecture logicielle [SWS_EcuM_04112]. Cette interface de service sert à lire le mode actuel de l'ECU et encapsule le groupe de modes currentMode sur la base du type de données EcuM_Mode [SWS_EcuM_04108].

Pendant le fonctionnement du système, l'utilisation s'effectue pour la signalisation des changements d'état :

• Appel et utilisation : Dès qu'un changement de mode survient, l'EcuM le signale aux composants logiciels (SW-C) via des ports de mode RTE [SWS_EcuM_04133]. Sous l'hypothèse de spécification du nom de port currentMode et lors de l'utilisation de l'API RTE directe, la fonction Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) est appelée à cette fin [SWS_EcuM_04133].
• Paramètre et valeur de retour : Le paramètre mode transmet à la RTE le nouveau mode à adopter [SWS_EcuM_04133]. La valeur de retour fournie par l'API de commutation de type Rte_StatusType n'est pas évaluée, mais doit obligatoirement être ignorée selon la spécification [SWS_EcuM_04133].
• Interaction : Un composant logiciel qui doit être informé des changements de mode doit requérir l'interface de commutation de mode EcuM_CurrentMode en tant que port requis (Required-Port) [SWS_EcuM_04133].

Utilisation et plage de valeurs

Le type de données EcuM_ShutdownModeType est basé sur uint16 et est fourni via le fichier d'en-tête Rte_EcuM_Type.h [SWS_EcuM_04101]. Il représente les modes configurés dans l'ECU State Manager. Sa plage de valeurs comprend :

• les modes de veille configurés selon EcuMSleepModeId [SWS_EcuM_04101] ainsi que
• les modes de réinitialisation configurés, calculés à partir de l'offset 256 + EcuMResetModeId [SWS_EcuM_04101].

Interaction et contexte d'appel

Le type est utilisé dans des services synchrones et réentrants de l'ECU Manager :

• EcuM_SelectShutdownTarget prend shutdownMode comme paramètre d'entrée afin de définir le mode de veille concret (pour la cible ECUM_SHUTDOWN_TARGET_SLEEP) ou le mécanisme de réinitialisation (pour la cible ECUM_SHUTDOWN_TARGET_RESET) [SWS_EcuM_02822].
• EcuM_GetShutdownTarget renvoie, via un paramètre de type pointeur vers EcuM_ShutdownModeType, quel mode de veille ou de réinitialisation configuré est sélectionné pour la cible d'arrêt actuelle [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget transmet le mode d'arrêt du processus d'arrêt précédent via un paramètre de sortie [SWS_EcuM_02825]. Cette fonctionnalité est également mise à la disposition des composants logiciels (SW-C) via l'interface de service EcuM_ShutdownTarget [SWS_EcuM_03011].

Gestion des erreurs et conditions limites

Les fonctions renvoient Std_ReturnType. Si, par exemple, un pointeur NULL est transmis à EcuM_GetShutdownTarget ou EcuM_GetLastShutdownTarget, l'appel échoue avec E_NOT_OK [SWS_EcuM_02824], [SWS_EcuM_02825]. En cas d'exécution réussie, les services signalent E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].