ECU State Manager (EcuM)

La función síncrona y reentrante EcuM_GoDownHaltPoll indica al módulo ECU State Manager que pase a un modo Sleep, a un Reset o al estado OFF en función del objetivo de apagado seleccionado previamente [SWS_EcuM_91002]. Está disponible a través del archivo de cabecera EcuM.h y posee el Service ID 0x2c [SWS_EcuM_91002].

Parámetros y autorización de llamada

Como único parámetro de entrada se transfiere UserID de tipo EcuM_UserType. Este identifica al usuario llamador. La llamada está estrictamente reglamentada: únicamente los usuarios preconfigurados pueden ejecutar esta función [SWS_EcuM_91002].

Valores de retorno y comportamiento de ejecución

El comportamiento de retorno depende de forma determinante del tipo de objetivo de apagado establecido [SWS_EcuM_91002]:

• E_NOT_OK: la solicitud no fue aceptada [SWS_EcuM_91002].
• E_OK: Si el objetivo es SLEEP, la función regresa con éxito con este estado tras salir del estado de reposo [SWS_EcuM_91002].
• Sin retorno: Si se seleccionó RESET o OFF como objetivo de apagado, la llamada a la función ya no regresa al llamador [SWS_EcuM_91002].

Restricciones y tratamiento de errores

Aunque la función se declara formalmente como reentrante, su ejecución conforme a lo previsto presupone la determinación previa de un objetivo de apagado válido [SWS_EcuM_91002]. En la especificación de la interfaz no se listan códigos de error DET o DEM específicos; un fallo o el rechazo de la solicitud se indica directamente a través del valor de retorno E_NOT_OK [SWS_EcuM_91002].

La función de servicio síncrona EcuM_Init inicializa el ECU State Manager e inicia el proceso ordenado de arranque de la unidad de control ([SWS_EcuM_02811]). Se declara a través de la cabecera EcuM.h con el ID de servicio 0x01, no recibe parámetros y no devuelve ningún valor de retorno ([SWS_EcuM_02811]). Formalmente catalogada como reentrante, EcuM_Init nunca regresa al llamador tras la llamada, ya que transfiere la ejecución al sistema operativo llamando a StartOS ([SWS_EcuM_02811]).

En el marco de su ejecución, la función procesa la secuencia StartPreOS definida y sus actividades en el orden exactamente predeterminado ([SWS_EcuM_02411], [SWS_EcuM_02684]). Una parte esencial de esta fase es la verificación de la coherencia de la configuración: el módulo comprueba dentro de EcuM_Init si el campo de estructura correspondiente es idéntico al valor de ECUM_CONFIGCONSISTENCY_HASH ([SWS_EcuM_02798]).

Además, EcuM_Init controla la inicialización de los controladores en sistemas multinúcleo ([SWS_EcuM_04145]). La función llama en cada núcleo individual a los callouts EcuM_AL_DriverInitZero así como a EcuM_AL_DriverInitOne ([SWS_EcuM_04145]). Para las implementaciones de los callouts rige el requisito de garantizar que en el núcleo respectivo activo solo se inicialicen aquellos módulos MCAL que efectivamente se ejecuten en dicho núcleo ([SWS_EcuM_04145]).

La función síncrona y no reentrante EcuM_StartupTwo implementa el estado STARTUP II del ECU State Manager [SWS_EcuM_02838]. La interfaz se declara a través del archivo de cabecera EcuM.h y posee el identificador de servicio 0x1a [SWS_EcuM_02838]. Según la firma de la función void EcuM_StartupTwo(void), la llamada no recibe parámetros de entrada, de entrada/salida ni de salida, y no devuelve ningún valor de retorno al llamante [SWS_EcuM_02838].

Si el módulo ECU Manager se activa mediante la función EcuM_StartupTwo, ejecuta las acciones de la secuencia StartPostOS [SWS_EcuM_02932].

Para la integración existen directrices esenciales relativas al contexto de llamada y a la concurrencia: la función debe llamarse obligatoriamente desde una tarea que se inicie directamente como consecuencia de StartOS [SWS_EcuM_02806]. Esto requiere que la llamada a EcuM_StartupTwo se realice bien desde una tarea de inicio automático (Autostart Task), bien desde una tarea que se inicie explícitamente [SWS_EcuM_02806]. Dado que la función está especificada como no reentrante, no debe tener lugar ninguna llamada simultánea ni múltiple [SWS_EcuM_02838].

La función de servicio síncrona EcuM_Shutdown (identificador de servicio 0x02) se proporciona a través del archivo de cabecera EcuM.h y asume el control de la ejecución para llevar a cabo las actividades de la fase «GO OFF II» [SWS_EcuM_02812]. Sirve para la terminación final del proceso de apagado [SWS_EcuM_02953].

Contexto de llamada y semántica

Típicamente, la función se llama desde el shutdown hook [SWS_EcuM_02812]. Según los requisitos, este hook está explícitamente obligado a llamar a EcuM_Shutdown para finalizar el proceso de apagado [SWS_EcuM_02953].

• Firma: void EcuM_Shutdown(void) con identificador de servicio 0x02 [SWS_EcuM_02812].
• Parámetros: No existen parámetros de entrada, de salida ni de entrada/salida [SWS_EcuM_02812].
• Valor de retorno: La interfaz no devuelve ningún valor de retorno [SWS_EcuM_02812].
• Sincronía: La llamada se ejecuta de forma síncrona [SWS_EcuM_02812].

Concurrencia y flujo de control

En la especificación, EcuM_Shutdown está declarada como reentrante [SWS_EcuM_02812]. Sin embargo, para el flujo del programa rige el requisito estricto de que EcuM_Shutdown no debe retornar al llamante [SWS_EcuM_02953]. Tras el procesamiento, la función apaga la unidad de control de forma definitiva o, alternativamente, desencadena un reinicio [SWS_EcuM_02953].

Uso y contexto de llamada

La función síncrona EcuM_SetState sirve para que el BswM comunique un cambio de estado al EcuM [SWS_EcuM_04122]. Como parámetro de entrada se transfiere state de tipo EcuM_StateType, el cual especifica el estado predeterminado por el BswM [SWS_EcuM_04122]. La función no posee valor de retorno [SWS_EcuM_04122].

Funcionamiento e interacción

Al ser llamada, la función establece el estado interno del EcuM en el valor del parámetro state [SWS_EcuM_04123]. Si el BswM establece de este modo un estado del EcuM, el EcuM indica el modo correspondiente a la RTE [SWS_EcuM_04116].

Manejo de errores

Si el valor transferido del parámetro state no es válido, EcuM_SetState no modifica el estado del EcuM [SWS_EcuM_04123]. Siempre que la notificación de errores de desarrollo (Development Error Reporting) esté activada, la función notifica adicionalmente en este caso de error el fallo ECUM_E_STATE_PAR_OUT_OF_RANGE al módulo DET [SWS_EcuM_04123].

Concurrencia e interfaz

La ejecución es síncrona y reentrante [SWS_EcuM_04122]. El servicio se declara a través del archivo de cabecera EcuM.h [SWS_EcuM_04122].

usar

La función síncrona y reentrante EcuM_RequestRUN sirve para solicitar el estado RUN al ECU State Manager [SWS_EcuM_04124]. Como parámetro se transfiere mediante user de tipo EcuM_UserType el identificador de la entidad solicitante; únicamente están autorizados los usuarios que ya se hayan dado a conocer al gestor de estados en el momento de la configuración [SWS_EcuM_04124]. La función devuelve E_OK si el EcuM ha aceptado la solicitud; de lo contrario, E_NOT_OK [SWS_EcuM_04124]. El servicio está declarado a través de la cabecera EcuM.h [SWS_EcuM_04124].

Tratamiento de errores y restricciones

Las solicitudes no deben anidarse: un usuario individual solo puede mantener como máximo una solicitud de RUN activa a la vez [SWS_EcuM_04125]. Si EcuM_RequestRUN detecta llamadas repetidas o duplicadas por parte del mismo usuario, se notifica el código de error ECUM_E_MULTIPLE_RUN_REQUESTS al DET con la detección de desarrollo activada [SWS_EcuM_03024], [SWS_EcuM_04125].

Interacción

Cada solicitud de estado establecida correctamente con EcuM_RequestRUN debe liberarse de nuevo tras finalizar la actividad. Para ello se dispone del servicio complementario EcuM_ReleaseRUN, asimismo síncrono y reentrante, al cual se transfiere el mismo ID de usuario [SWS_EcuM_04127].

usar

La función síncrona EcuM_ReleaseRUN (ID de servicio 0x04) sirve para liberar una solicitud de estado RUN registrada previamente a través de EcuM_RequestRUN [SWS_EcuM_04127]. La interfaz se proporciona a través de la cabecera EcuM.h y está prevista principalmente para la implementación de puertos AUTOSAR [SWS_EcuM_04127]. Como parámetro de entrada, la función espera el identificador de usuario user de tipo EcuM_UserType, el cual identifica de forma unívoca la entidad liberadora dentro del módulo [SWS_EcuM_04127].

El valor de retorno de tipo Std_ReturnType indica con E_OK que el módulo ha aceptado con éxito la solicitud de liberación [SWS_EcuM_04127]. Si la liberación no se ha podido procesar, el servicio devuelve el valor de error E_NOT_OK [SWS_EcuM_04127].

Tratamiento de errores y concurrencia

En la especificación no se indican códigos de error específicos, errores de desarrollo (DET) o errores de producción (DEM); el rechazo de una solicitud se manifiesta exclusivamente a través de la devolución de E_NOT_OK [SWS_EcuM_04127]. Es de suponer (interpretación:) que la devolución de E_NOT_OK se produce presumiblemente cuando no existe ninguna solicitud activa para el ID de usuario especificado o cuando se ha transferido un valor de parámetro no permitido. Pregunta Q-cbe9031cffe1be81 (abierta)

La función está declarada como reentrante y, por tanto, se puede invocar en contextos de ejecución concurrentes [SWS_EcuM_04127]. Como condición de orden funcional, la invocación requiere obligatoriamente que el usuario correspondiente haya solicitado previamente el estado mediante EcuM_RequestRUN [SWS_EcuM_04127].

Interacción

El módulo EcuM proporciona este servicio para finalizar el mantenimiento del estado RUN a través de puertos definidos [SWS_EcuM_04127]. Para la configuración de la RTE y la interacción con el comportamiento en tiempo de ejecución local de la RTE, la especificación define el comportamiento interno del EcuStateManager con varias Runnable Entities ejecutables de forma concurrente [SWS_EcuM_03018].

usar

La función síncrona EcuM_RequestPOST_RUN sirve para solicitar el estado POST RUN al ECU State Manager ([SWS_EcuM_04128]). El llamador se identifica mediante el parámetro user, debiendo haberse dado a conocer previamente al gestor de estados cada entidad solicitante en el momento de la configuración ([SWS_EcuM_04128]). El servicio está declarado en la cabecera EcuM.h, previsto para la implementación de puertos AUTOSAR y confirma una aceptación correcta con E_OK o un rechazo con E_NOT_OK ([SWS_EcuM_04128]).

Manejo de errores

Siempre que la detección de errores de desarrollo esté activada, una nueva llamada por parte del mismo usuario hace que EcuM_RequestPOST_RUN notifique el error ECUM_E_MULTIPLE_RUN_REQUESTS al DET ([SWS_EcuM_03025]). Interpretación: en caso de tales solicitudes múltiples o con ID de usuario no válidos, es probable que el servicio responda con E_NOT_OK ([SWS_EcuM_04128]). Pregunta Q-b5bbd7d5b53e76ba (abierta)

Concurrencia e interacción

La función está diseñada como reentrante ([SWS_EcuM_04128]). En el módulo, las solicitudes para RUN y POST RUN deben rastrearse de forma estrictamente independiente entre sí mediante dos variables autónomas ([SWS_EcuM_04128]). Cada solicitud registrada a través de este servicio mantiene activo el estado POST RUN hasta que se retira explícitamente mediante la llamada complementaria de EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]).

Uso y semántica

La función síncrona y reentrante EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) sirve para liberar una solicitud de POST-RUN establecida previamente mediante EcuM_RequestPOST_RUN. A través del parámetro de entrada user de tipo EcuM_UserType se transfiere el identificador de la entidad que vuelve a liberar el estado POST-RUN. La interfaz está disponible a través del archivo de cabecera EcuM.h y está diseñada principalmente para la implementación de puertos AUTOSAR ([SWS_EcuM_04129]).

Valores de retorno y tratamiento de errores

La función devuelve el estado Std_ReturnType ([SWS_EcuM_04129]):

• E_OK: La solicitud de liberación fue aceptada con éxito por el ECU State Manager.
• E_NOT_OK: La solicitud de liberación fue rechazada. Interpretación: Es probable que se produzca un rechazo con E_NOT_OK si no había ninguna solicitud activa registrada para el usuario indicado o si se transfirió un identificador de usuario no válido. Pregunta Q-67bd8594612defca (abierta)

Concurrencia e interacción

El servicio está especificado como reentrante ([SWS_EcuM_04129]), de modo que se permiten invocaciones simultáneas por parte de varias entidades. La función forma parte del comportamiento interno del módulo EcuM ([SWS_EcuM_03018]). La invocación presupone lógicamente que la entidad haya solicitado previamente la fase POST RUN ([SWS_EcuM_04129]). Interpretación: Por lo general, es de prever que la invocación se realice desde componentes de software a través de puertos de la RTE tan pronto como hayan concluido sus actividades de post-ejecución antes de la desconexión. Pregunta Q-81f71656d4debb4a (abierta)

La función de servicio síncrona EcuM_SelectShutdownTarget sirve para seleccionar el destino de apagado (shutdown target) para la unidad de control y se proporciona a través del archivo de cabecera EcuM.h, así como formando parte de la interfaz de puerto del módulo administrador de la ECU [SWS_EcuM_02822]. Mediante la llamada, el destino de apagado interno se establece al valor del parámetro transmitido shutdownTarget [SWS_EcuM_00624].

La función espera dos parámetros de entrada [SWS_EcuM_02822]:

• shutdownTarget: determina el destino seleccionado para el apagado [SWS_EcuM_02822].
• shutdownMode: contiene el identificador de un modo de reposo (si el destino es ECUM_SHUTDOWN_TARGET_SLEEP) o de un mecanismo de reinicio (si el destino es ECUM_SHUTDOWN_TARGET_RESET) de acuerdo con la configuración [SWS_EcuM_02822].

La llamada no inicia actividades inmediatas de configuración ni de ejecución (setup), sino que simplemente almacena los valores para su uso posterior en la fase SHUTDOWN o SLEEP [SWS_EcuM_02585].

En cuanto a la concurrencia, la función está especificada como reentrante [SWS_EcuM_02822]. En el RTE-Internal-Behavior del ECU State Manager, la correspondiente Runnable Entity SelectShutdownTarget está declarada con canbeInvokedConcurrently = TRUE [SWS_EcuM_03018], por lo que las llamadas paralelas están permitidas.

El valor de retorno de tipo Std_ReturnType señala con E_OK que el nuevo destino de apagado se ha establecido con éxito, y con E_NOT_OK que la adopción ha fallado [SWS_EcuM_02822]. La especificación no menciona en este punto causas de error concretas para E_NOT_OK ni mensajes DET; es de suponer que combinaciones no permitidas o no configuradas de destino y modo conducen al rechazo. Pregunta Q-e916f3a6ac0bf47e (abierta)

La función síncrona EcuM_SelectShutdownCause sirve para seleccionar la causa de un apagado de la ECU y está disponible a través del archivo de cabecera EcuM.h [SWS_EcuM_04050].

Uso y semántica:

• Parámetro: El parámetro de entrada target de tipo EcuM_ShutdownCauseType transfiere la causa de desconexión seleccionada [SWS_EcuM_04050].
• Valor de retorno: Un valor de retorno de tipo Std_ReturnType señala con E_OK que la nueva causa se ha establecido correctamente, y con E_NOT_OK, que el ajuste ha fallado [SWS_EcuM_04050].
• Ejecución: El servicio opera de forma síncrona bajo el Service ID 0x1b y está especificado como reentrante [SWS_EcuM_04050].

Concurrencia e interacción:

La función forma parte de la interfaz de puerto del módulo ECU Manager [SWS_EcuM_04050]. Para la configuración de la RTE local, en el comportamiento interno EcuStateManager está definida la Runnable Entity SelectShutdownCause con el símbolo EcuM_SelectShutdownCause, teniendo asignada la propiedad canbeInvokedConcurrently = TRUE [SWS_EcuM_03018].

Tratamiento de errores:

En el alcance de la especificación no se indican mensajes DET o DEM específicos; los estados de error al establecer la causa se indican exclusivamente a través del valor de retorno E_NOT_OK [SWS_EcuM_04050].

La función de servicio síncrona EcuM_ClearWakeupEvent (ID de servicio 0x16) sirve para restablecer eventos de activación y está disponible a través del archivo de cabecera EcuM.h [SWS_EcuM_02828]. Como parámetro recibe la máscara de bits sources de tipo EcuM_WakeupSourceType y no posee valor de retorno [SWS_EcuM_02828].

Al producirse la llamada, todos los eventos pendientes establecidos como bit en sources se borran de tres variables internas del módulo [SWS_EcuM_02683]:

• de la variable interna para eventos de activación pendientes (pending wakeup events),
• de la variable interna para eventos de activación validados (validated events), así como
• de la variable interna para eventos de activación expirados (expired events) [SWS_EcuM_02683].

En cuanto al contexto de llamada, EcuM_ClearWakeupEvent puede llamarse de forma flexible desde el contexto de interrupción, desde el contexto regular de OS, así como desde un contexto libre de OS [SWS_EcuM_02807]. Al mismo tiempo, sin embargo, la función está especificada con carácter vinculante como no reentrante (Non-Reentrant) y no interrumpible (Non-Interruptible) [SWS_EcuM_02828]. Interpretación: dado que la función está permitida en diferentes contextos pero no es interrumpible, el integrador o llamador probablemente deba garantizar de manera organizativa que no tengan lugar llamadas simultáneas o que se interrumpan mutuamente. Pregunta Q-71a4b1b218505a1c (abierta)

La función síncrona EcuM_AbortWakeupAlarm sirve para cancelar una alarma de despertar establecida previamente por un usuario [SWS_EcuM_04061]. La interfaz está disponible a través del archivo de cabecera EcuM.h y forma parte de la interfaz de puerto del módulo ECU Manager [SWS_EcuM_04061].

Parámetros y valores de retorno

• user (In): identificador del usuario del tipo EcuM_UserType que desea cancelar la alarma de despertar [SWS_EcuM_04061]. No existen parámetros de entrada/salida ni de salida pura [SWS_EcuM_04061].
• E_OK: el servicio se ejecutó correctamente y la alarma se canceló [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE: no se encontró ninguna alarma activa que pertenezca al usuario transferido [SWS_EcuM_04061].
• E_NOT_OK: la ejecución del servicio ha fallado [SWS_EcuM_04061].

Concurrencia e interacción

La función posee el ID de servicio 0x24 y está especificada como reentrante [SWS_EcuM_04061]. Por lo tanto, las invocaciones para diferentes usuarios pueden realizarse de manera concurrente. El comportamiento interno del ECU Manager define las entidades ejecutables para la configuración de la RTE local [SWS_EcuM_03018]; como parte de la interfaz de puerto del módulo, es de suponer que la invocación sea iniciada típicamente por componentes de software a través de la RTE. Pregunta Q-2c8f004d9f00bbd3 (abierta)

La función síncrona y reentrante EcuM_SetClock sirve, conforme a [SWS_EcuM_04064], para establecer la hora interna del ECU State Manager en un valor predeterminado. Como parte de la interfaz de puerto del ECU Manager, la función puede integrarse y llamarse a través del archivo de cabecera EcuM.h [SWS_EcuM_04064].

El propósito principal de la interfaz es la prueba de servicios de alarma: las alarmas cuya ejecución regular requeriría días pueden verificarse en modo de prueba mediante el ajuste selectivo de la hora [SWS_EcuM_04064]. Para ello se transfieren dos parámetros de entrada:

• user (tipo EcuM_UserType): identificador del llamador o usuario que desea establecer la hora.
• time (tipo EcuM_TimeType): indicación de tiempo absoluto en segundos desde la conexión de la batería (Battery Connect).

Como valor de retorno, el servicio suministra el estado Std_ReturnType con E_OK en caso de ejecución correcta o E_NOT_OK en caso de error [SWS_EcuM_04064]. En la interfaz no se especifican causas de error concretas ni mensajes DET; presumiblemente, la transferencia de identificadores de usuario no autorizados o de valores temporales no válidos da lugar al retorno de E_NOT_OK. Pregunta Q-248768580c0309e8 (abierta)

En cuanto al comportamiento interno del módulo y a la configuración de la RTE, la función se integra en la estructura de las Runnable Entities del EcuStateManager [SWS_EcuM_03018].

La función síncrona EcuM_SelectBootTarget sirve para la selección de un objetivo de arranque para la unidad de control, forma parte de la interfaz de puerto del ECU Manager y está disponible a través de la cabecera EcuM.h [SWS_EcuM_02835]. El destino deseado se transmite mediante el parámetro de entrada target de tipo EcuM_BootTargetType [SWS_EcuM_02835].

Como valor de retorno, la función señala E_OK si el nuevo objetivo de arranque fue aceptado por el EcuM; en caso contrario, E_NOT_OK [SWS_EcuM_02835]. La implementación debe almacenar el objetivo seleccionado de un modo que sea compatible con el bootloader [SWS_EcuM_02247]. El valor establecido actualmente puede consultarse mediante el servicio complementario EcuM_GetBootTarget [SWS_EcuM_02836].

La función está especificada como reentrante [SWS_EcuM_02835]; en el marco del comportamiento interno para la configuración de la RTE, la Runnable Entity SelectBootTarget está declarada con canbeInvokedConcurrently = TRUE [SWS_EcuM_03018]. Como restricción, este servicio está previsto exclusivamente para componentes de software (SW-Cs) relacionados con el diagnóstico o la gestión de arranque, y puede depender del bootloader concretamente utilizado [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent es un servicio síncrono (ID de servicio 0x14) que señala al ECU Manager que las fuentes de activación transmitidas en el parámetro sources han sido validadas con éxito ([SWS_EcuM_02829]). Tras la activación, el ECU State Manager espera esta confirmación en la secuencia de validación. Al producirse la llamada, la función detiene el temporizador de tiempo de espera en curso de la validación ([SWS_EcuM_02710]) y registra los eventos transmitidos mediante una operación lógica OR de la máscara de bits en la variable interna para eventos de activación validados ([SWS_EcuM_04078]).

La función es reentrante ([SWS_EcuM_02829]) y puede llamarse tanto desde el contexto de tarea como desde el contexto de interrupción ([SWS_EcuM_02345]). Si el ECU Manager se encuentra en el estado RUN, la llamada carece de efecto para todas las fuentes de activación, siempre que no se trate de canales de comunicación ([SWS_EcuM_02790]). En cambio, para las fuentes asignadas a un canal de comunicación, el servicio surte un efecto ilimitado en cualquier fase de la ECU ([SWS_EcuM_02791]).

En el flujo global, el servicio interactúa estrechamente con la validación de activación y la gestión de comunicación:

• Comprobación de validación: El ECU Manager llama para la verificación al callout EcuM_CheckValidation; si se detecta un evento de activación válido, la confirmación tiene lugar a través de EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Configuración: Si no hay configurado ningún protocolo de validación para una fuente de activación (EcuMValidationTimeout), ya EcuM_SetWakeupEvent implica la llamada a EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Notificación: Si para la fuente de activación está configurado EcuMComMChannelRef, el servicio llama a ComM_EcuM_WakeUpIndication ([SWS_EcuM_02645]). En caso de estar configurado EcuMComMPNCRef, se activa adicionalmente ComM_EcuM_PNCWakeUpIndication para cada PNC referenciado ([SWS_EcuM_04140]).

La función de callback síncrona y no reentrante EcuM_ErrorHook (proporcionada mediante EcuM_Externals.h) es llamada por el ECU State Manager en cuanto se producen errores graves que hacen imposible continuar con el procesamiento regular y exigen la detención de la unidad de control [SWS_EcuM_02904]. A través del parámetro de transferencia reason se transmite la causa específica del error [SWS_EcuM_02904].

Entre las causas de error definidas se encuentran ECUM_E_RAM_CHECK_FAILED y ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. Si la comprobación de la RAM falla durante la activación, el ECU Manager está obligado a activar EcuM_ErrorHook con el motivo ECUM_E_RAM_CHECK_FAILED [SWS_EcuM_02987]. Además, el tratamiento de errores tiene lugar a través de este hook si falla una llamada a una función del sistema operativo y no se ha especificado ninguna otra reacción frente a errores; en este caso, el EcuM permanece en el estado previo [SWS_EcuM_04139].

Para el integrador de sistemas rigen las siguientes condiciones marco durante la implementación:

• Modalidad de parada de la unidad de control: El integrador elige el modo en que se detiene la ECU (p. ej., restablecimiento, parada, reinicio o estado seguro) [SWS_EcuM_02904]. Interpretación: ante medidas drásticas como un restablecimiento o una parada, la función típicamente ya no debería regresar al control de flujo regular. Pregunta Q-59c23e3a2569f670 (abierta)
• Notificación de error al DEM: Queda a discreción del integrador si el error se reenvía al DEM, siempre que se garantice que el DEM no escriba en bloques de NVRAM dañados [SWS_EcuM_02987].

Uso y condiciones de llamada

El módulo ECU State Manager llama a la función callout EcuM_AL_SetProgrammableInterrupts para configurar y establecer las interrupciones correspondientes en unidades de control con controladores de interrupción programables [SWS_EcuM_04085]. Sin embargo, la ejecución de este callout solo tiene lugar si el parámetro de configuración EcuMSetProgrammableInterrupts está establecido en el valor true [SWS_EcuM_04085]. Si este parámetro no está activado, la llamada no se efectúa [SWS_EcuM_04085]. Para integradores y controladores de plataforma, la declaración de la interfaz se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_04085].

La interfaz posee la sintaxis void EcuM_AL_SetProgrammableInterrupts (void) y está asignada al identificador de servicio 0x4A [SWS_EcuM_04085]. La llamada carece totalmente de parámetros: no se transfieren parámetros de entrada, de entrada/salida ni de salida, y la función no devuelve ningún valor de retorno al módulo llamante [SWS_EcuM_04085].

Concurrencia y restricciones

Para EcuM_AL_SetProgrammableInterrupts, en la especificación se establece un comportamiento de ejecución asíncrono (Asynchronous) [SWS_EcuM_04085]. Con respecto a la concurrencia, la función está clasificada como no reentrante (Non Reentrant) [SWS_EcuM_04085]. Para la integración, esto significa que las llamadas paralelas o anidadas a la interfaz no están permitidas y que la configuración relativa a las interrupciones debe realizarse sin reentrancias simultáneas [SWS_EcuM_04085].

usar

La función callout EcuM_AL_DriverInitZero (ID de servicio 0x31) se llama de forma síncrona, no posee parámetros ni valor de retorno y no es reentrante [SWS_EcuM_02905]. Está declarada a través de la cabecera EcuM_Externals.h [SWS_EcuM_02905]. La función sirve para proporcionar inicializaciones tempranas de controladores, así como actividades básicas de inicio relacionadas con el hardware, que resultan estrictamente necesarias para poder cargar posteriormente los datos de configuración post-build [SWS_EcuM_02905].

Restricciones y funcionamiento multinúcleo

Para la implementación y la ejecución rigen directrices y restricciones específicas:

• Clases de configuración: En este punto temprano solo se permite utilizar módulos configurables como Pre-Compile o Link-Time [SWS_EcuM_02905]. Los controladores configurables post-build aún no están disponibles aquí.
• Contexto de llamada: La función es llamada por EcuM_Init en cada Core del sistema [SWS_EcuM_04145].
• Inicialización específica de Core: La implementación del callout debe garantizar que en el Core actualmente activo solo se inicialicen aquellos módulos MCAL que realmente se ejecutan en este Core específico [SWS_EcuM_04145].

No se definen valores de retorno, códigos de error específicos ni notificaciones a través de DET o DEM para este callout [SWS_EcuM_02905].

La función EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) es un callout síncrono del ECU State Manager que se proporciona a través del archivo de cabecera EcuM_Externals.h y posee el Service-ID 0x32. La interfaz no posee parámetros de entrada, salida ni de entrada/salida ([SWS_EcuM_02906]). Su propósito principal consiste en determinar durante el proceso de inicialización, en función de las condiciones del hardware o de la memoria, qué conjunto de datos de configuración post-build se debe utilizar para el curso posterior del inicio del sistema ([SWS_EcuM_02906]).

Para determinar la configuración, el callout debe evaluar criterios externos o residentes, como el estado de un pin de puerto o un valor en la NVRAM ([SWS_EcuM_02906]). A continuación, la función debe cargar estos datos de configuración en un segmento de memoria al que puedan acceder todos los módulos BSW ([SWS_EcuM_02906]). Como valor de retorno, devuelve un puntero de tipo const EcuM_ConfigType* a la configuración post-build de EcuM ([SWS_EcuM_02906]). Este puntero constituye la base de partida común para toda la BSW, ya que la estructura contiene punteros a las respectivas configuraciones post-build de todos los demás módulos BSW ([SWS_EcuM_02906]).

En cuanto al comportamiento de llamada, la función está especificada como síncrona y no reentrante (Non Reentrant) ([SWS_EcuM_02906]). Para este callout no se definen códigos de error específicos, valores de retorno de error particulares ni interfaces hacia DET o DEM ([SWS_EcuM_02906]). Por lo tanto, debe considerarse como una interpretación de los requisitos que una implementación de callout específica de la aplicación debe gestionar los estados de error de forma autónoma, ya que la ausencia de un puntero de configuración válido presumiblemente impediría el arranque ordenado de los módulos BSW dependientes. Pregunta Q-b9487647fb39a2e2 (abierta)

Uso y semántica

La función EcuM_AL_DriverInitOne es una función callout del administrador de estados de la ECU (EcuM), proporcionada a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02907]. Su tarea principal consiste en llevar a cabo la inicialización de controladores así como otras actividades de arranque de la unidad de control relacionadas con el hardware en caso de un reinicio por encendido (Power-on-Reset) [SWS_EcuM_02907]. Al tratarse de un callout, es de suponer que la implementación concreta de la inicialización de hardware y controladores corre a cargo del integrador del sistema correspondiente. Pregunta Q-e22baf2fa31cf075 (abierta)

La interfaz posee la signatura C void EcuM_AL_DriverInitOne (void) y está asignada al Service-ID 0x33 [SWS_EcuM_02907]. No acepta ningún parámetro de entrada ni devuelve valor alguno a quien la invoca [SWS_EcuM_02907].

Concurrencia y restricciones

Para la llamada y el comportamiento en tiempo de ejecución se aplican, según [SWS_EcuM_02907], las siguientes condiciones de contorno:

• Sincronía: La ejecución se realiza de forma síncrona (Synchronous), de modo que quien realiza la llamada espera a que finalicen las actividades de arranque.
• Reentrancia: La función está definida como no reentrante (Non Reentrant); una llamada múltiple simultánea o con interrupción no está permitida.
• Contexto de llamada: La activación está especificada exclusivamente para la fase de inicialización inmediatamente posterior a un reinicio por encendido (Power-on-Reset).

Manejo de errores

Dado que EcuM_AL_DriverInitOne presenta el tipo de retorno void, no existe a nivel de interfaz una retroalimentación directa sobre el éxito o fallo de la inicialización [SWS_EcuM_02907]. En el alcance de la presente especificación no se definen códigos de error específicos ni mensajes a DET o DEM para este callout.

La función EcuM_LoopDetection es un callout del ECU State Manager con el ID de servicio 0x4B, que se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_04137].

Uso y contexto de llamada

Siempre que el parámetro de configuración EcuMResetLoopDetection esté establecido en true, este callout se invoca de forma síncrona en cada arranque (Startup) [SWS_EcuM_04137]. La función no posee parámetros de entrada, entrada/salida ni salida, y no devuelve ningún valor (signatura: void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Concurrencia y restricciones

La ejecución de EcuM_LoopDetection está especificada como síncrona y no reentrante (Non Reentrant) [SWS_EcuM_04137]. Dado que se trata de un callout, la implementación concreta de la detección de bucles corresponde típicamente al integrador o usuario para registrar bucles de reinicio repetidos durante el arranque del sistema.

usar

La función EcuM_OnGoOffOne sirve para anunciar que se ha alcanzado el estado del sistema GO OFF I y ofrecer al diseñador del sistema la posibilidad de tomar las medidas oportunas inmediatamente antes del cambio [SWS_EcuM_02916]. La función se ejecuta de forma síncrona, no espera parámetros de transferencia (ni in ni inout) y no devuelve ningún valor de retorno (void) [SWS_EcuM_02916]. Dado que la interfaz se declara a través del archivo de cabecera EcuM_Externals.h, es comprensible suponer que se trata de una función callout específica del usuario implementada en el código de integración [SWS_EcuM_02916]. Pregunta Q-93de53c47a5a6142 (abierta)

Manejo de errores

En la especificación de EcuM_OnGoOffOne no figuran errores de desarrollo (DET), errores de producción (DEM) ni valores específicos de retorno de error [SWS_EcuM_02916]. De ello se deduce que el llamante no espera una gestión de errores estandarizada y que los posibles casos excepcionales deben gestionarse de manera autónoma dentro de la implementación específica del usuario [SWS_EcuM_02916].

Concurrencia y restricciones

Para el contexto de llamada y el comportamiento en tiempo de ejecución se han establecido las siguientes propiedades [SWS_EcuM_02916]:

• Reentrancia: La función está especificada como no reentrante (Non Reentrant) y en ningún caso debe llamarse de forma paralela o anidada [SWS_EcuM_02916].
• Sincronía: La semántica es estrictamente síncrona (Synchronous), de modo que el llamante espera el retorno completo de la función [SWS_EcuM_02916].
• Identificador de servicio: El servicio está representado internamente por el identificador hexadecimal 0x3C [SWS_EcuM_02916].

Debido al comportamiento síncrono y al inminente cambio al estado GO OFF I, es de suponer que deben evitarse las operaciones bloqueantes para no retrasar indebidamente el proceso de apagado o de transición [SWS_EcuM_02916]. Pregunta Q-93f5e23c581f0c38 (abierta)

Según la especificación, la función síncrona EcuM_OnGoOffTwo sirve para permitir al diseñador del sistema recibir la notificación de que el estado GO OFF II es inminente [SWS_EcuM_02917]. La llamada se realiza sin parámetros, sin parámetros In, Inout u Out, y no devuelve ningún valor a quien la invoca [SWS_EcuM_02917].

En cuanto al contexto de ejecución y a la concurrencia, la interfaz cuenta con el Service-ID 0x3D y está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02917]. Se proporciona a través de la cabecera EcuM_Externals.h [SWS_EcuM_02917]. Interpretación: Dado que la declaración se encuentra en EcuM_Externals.h y sirve para la notificación al diseñador del sistema, es de suponer que la función está concebida como un callout síncrono de la gestión de la unidad de control que se invoca antes de la transición al estado GO OFF II. Pregunta Q-bb0ae6e4632de827 (abierta)

Debido a su propiedad como interfaz no reentrante, la llamada no debe repetirse en paralelo ni con interrupciones [SWS_EcuM_02917]. En el alcance de la especificación no se definen códigos de error específicos, respuestas a DET o DEM ni mecanismos especiales de tratamiento de errores [SWS_EcuM_02917].

usar

La función callout EcuM_AL_SwitchOff forma parte del módulo ECU State Manager (EcuM) y sirve para albergar el código específico del usuario destinado a desconectar la alimentación de tensión de la unidad de control [SWS_EcuM_02920]. La interfaz está definida como síncrona, posee el Service-ID 0x3E y se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02920].

De acuerdo con la especificación, la función no recibe parámetros de entrada, entrada/salida ni salida, y carece de valor de retorno (void) [SWS_EcuM_02920]. Si el hardware de la unidad de control no puede dejarse sin tensión de forma autónoma, la especificación prevé que activar un reinicio puede representar, en su lugar, una reacción adecuada [SWS_EcuM_02920].

Interacción y concurrencia

La llamada a EcuM_AL_SwitchOff la realiza obligatoriamente el módulo ECU Manager en cuanto el objetivo de apagado (Shutdown Target) seleccionado es OFF [SWS_EcuM_04075]. En relación con el comportamiento frente a la concurrencia, el callout está establecido como no reentrante (Non Reentrant) [SWS_EcuM_02920]. Interpretación: Dado que el objetivo de la función es la desconexión completa de la alimentación de corriente o, subsidiariamente, un reinicio, es de suponer que este callout represente el paso final de la secuencia de apagado, tras el cual ya no tiene lugar ninguna otra ejecución regular de programa. Pregunta Q-e8a1aaa1413bbea9 (abierta)

Manejo de errores

Para el callout no se contemplan en la especificación códigos de error específicos, mecanismos de tratamiento de errores ni mensajes a DET o DEM [SWS_EcuM_02920].

El callout EcuM_AL_Reset sirve para alojar el código específico de la integración responsable de restablecer la unidad de control ([SWS_EcuM_04065]). La interfaz se declara a través del archivo de cabecera EcuM_Externals.h y posee el ID de servicio 0x4C ([SWS_EcuM_04065]).

La invocación de la función se realiza de forma síncrona y está definida como no reentrante (Non Reentrant) ([SWS_EcuM_04065]). Como único parámetro de entrada se transfiere reset del tipo EcuM_ResetType, que determina el tipo específico de reinicio que debe ejecutarse ([SWS_EcuM_04065]). La función no posee valor de retorno (void) y no cuenta con parámetros de salida ni de entrada/salida ([SWS_EcuM_04065]).

En la interacción de la fase de apagado, se establece que el módulo ECU Manager debe invocar obligatoriamente el callout EcuM_AL_Reset si el objetivo de apagado está fijado en RESET ([SWS_EcuM_04074]). Para el callout, en la especificación no se contemplan ni códigos de error ni notificaciones a DET o DEM ([SWS_EcuM_04065]). Interpretación: es probable que el callout ejecute comandos de control cercanos al hardware que provoquen directamente el reinicio de la MCU. Pregunta Q-1e318404843faabd (abierta)

La función EcuM_EnableWakeupSources es un callout síncrono del ECU Manager con el Service-ID 0x3F, que se declara a través de la cabecera EcuM_Externals.h [SWS_EcuM_02918]. Sirve para informar al desarrollador del sistema de que el estado SLEEP es inminente, de modo que las fuentes de despertar indicadas en el campo de bits wakeupSource (tipo EcuM_WakeupSourceType) puedan prepararse y ajustarse en consecuencia [SWS_EcuM_02918].

Uso e interacción

El ECU Manager ejecuta EcuM_EnableWakeupSources para configurar las fuentes de despertar de cara al próximo modo Sleep; esto se lleva a cabo para cada fuente de despertar configurada en EcuMWakeupSourceMask para el modo Sleep previsto [SWS_EcuM_02389]. La función no tiene valor de retorno (void) y espera como parámetro de entrada el campo de bits wakeupSource [SWS_EcuM_02918].

Concurrencia y restricciones

• Reentrancia: La función está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02918].
• Sincronicidad: El procesamiento se realiza de manera síncrona [SWS_EcuM_02918].
• Tratamiento de errores: En el alcance de la especificación de la interfaz no se definen mensajes de error específicos de DET o DEM [SWS_EcuM_02918].

La función EcuM_GenerateRamHash sirve para generar un valor de verificación de RAM en el contexto del ECU State Manager, remitiendo la especificación a EcuM_CheckRamHash en lo referente a su modo de funcionamiento [SWS_EcuM_02919]. El valor de verificación generado sirve presumiblemente para la posterior verificación de integridad de la memoria de trabajo en relación con estados de suspensión o reposo. Pregunta Q-7f316b389e1609c0 (abierta)

Uso e interfaz

El servicio posee el Service-ID 0x40 y la signatura void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. La función no tiene parámetros de entrada, salida ni entrada/salida y no devuelve ningún valor. La ejecución se realiza de forma síncrona.

Concurrencia y restricciones

La función está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02919]. Por consiguiente, no debe llamarse con interrupciones ni en paralelo desde múltiples contextos. La declaración se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02919]. Interpretación: debido a su definición en EcuM_Externals.h, es de suponer que se trata de un callout que debe implementarse de forma específica para la aplicación, invocado por el ECU State Manager en un momento oportuno del flujo de estados. Pregunta Q-2f53f1a19cee079c (abierta)

Manejo de errores

Para EcuM_GenerateRamHash no se definen en [SWS_EcuM_02919] códigos de error específicos ni mensajes de DET o DEM.

Uso y contexto de llamada

La función EcuM_SleepActivity representa un callout del ECU State Manager proporcionado en el archivo de cabecera EcuM_Externals.h con el identificador de servicio 0x41 [SWS_EcuM_02928]. La llamada se produce periódicamente en todos los modos de reposo con frecuencia de reloj de procesador reducida (reduced clock sleep modes) [SWS_EcuM_02928]. La función posee la firma void EcuM_SleepActivity(void), opera de forma síncrona y no acepta parámetros de entrada, de salida ni de entrada/salida [SWS_EcuM_02928].

Tareas funcionales e interacción

El propósito de este callout es la realización de actividades durante el reposo: está explícitamente previsto y permitido realizar consultas periódicas (polling) de fuentes de reactivación dentro de EcuM_SleepActivity [SWS_EcuM_02928]. Además, se permite llamar a funciones de notificación de reactivación directamente desde el callout para indicar al ECU State Manager la finalización del estado de reposo [SWS_EcuM_02928].

Concurrencia y restricciones

La interfaz está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02928]. Dado que el callout no entrega ningún valor de retorno y no hay parámetros de error definidos, a través de la interfaz de la función no se realiza ningún tratamiento directo de errores mediante códigos de error o notificadores de fallos como DET o DEM [SWS_EcuM_02928].

Uso y contexto de llamada

Según [SWS_EcuM_04096], el firmware de la ECU invoca la interfaz síncrona EcuM_StartCheckWakeup para iniciar el temporizador CheckWakeupTimer para una fuente de despertar determinada. Para ello, a la función se le pasa el parámetro WakeupSource del tipo EcuM_WakeupSourceType. No posee valor de retorno (void) y se proporciona a través del archivo de cabecera EcuM_Externals.h.

Secuencia y condiciones

La ejecución de la función depende de la configuración de la fuente de despertar [SWS_EcuM_04096]:

• Si para la fuente de despertar en cuestión se ha configurado EcuMCheckWakeupTimeout > 0, se inicia el CheckWakeupTimer correspondiente.
• Si se aplica EcuMCheckWakeupTimeout <= 0, el EcuM ignora por completo la invocación de la función.

Concurrencia y tratamiento de errores

La función está especificada como no reentrante (Non Reentrant) [SWS_EcuM_04096]. Por consiguiente, el invocador debe asegurarse de que las llamadas para la misma u otras fuentes de despertar no se produzcan de manera concurrente. Para esta invocación no se especifican códigos de error concretos ni notificaciones a DET o DEM; una invocación en caso de un timeout no positivo queda sin consecuencias según la especificación, lo que presumiblemente puede interpretarse como una interceptación tolerante de comprobaciones de temporizador irrelevantes [SWS_EcuM_04096]. Pregunta Q-19d98b03d3ee7504 (abierta)

El callout EcuM_CheckWakeup sirve para comprobar y sondear fuentes de despertar, así como para configurar el PLL tras un evento de despertar [SWS_EcuM_02929]. La función se proporciona a través del archivo de cabecera EcuM_Externals.h y posee el Service-ID 0x42 [SWS_EcuM_02929].

Contexto de llamada y semántica

• Signatura y parámetros: La función se ejecuta de forma síncrona (Synchronous), no tiene valor de retorno y espera como parámetro de entrada wakeupSource del tipo EcuM_WakeupSourceType [SWS_EcuM_02929].
• Invocador: el callout es invocado por EcuM para consultar cíclicamente una fuente de despertar. Además, debe ser invocado obligatoriamente por la rutina de servicio de interrupción (ISR) de una fuente de despertar para configurar el PLL y comprobar otras fuentes de despertar conectadas a la misma interrupción [SWS_EcuM_02929].
• Bucle de sondeo: en la secuencia de sondeo, el EcuM invoca repetidamente los callouts EcuM_SleepActivity y EcuM_CheckWakeup en un bucle bloqueante hasta que un evento de despertar se notifica como pendiente o validado [SWS_EcuM_03020].

Restricciones y tratamiento de errores

La función está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02929]. Dado que las invocaciones proceden tanto del flujo bloqueante de la secuencia de sondeo como de contextos de ISR, la integración debería tener que garantizar que no se produzcan invocaciones concurrentes no coordinadas. Pregunta Q-8bc8f164670a0911 (abierta) No se definen códigos de error específicos ni notificaciones de error a DET o DEM para este callout.

La función síncrona EcuM_EndCheckWakeup es llamada por módulos de software cuando la comprobación asíncrona de una fuente de activación (como en el caso de un controlador de transceptor CAN asíncrono) arroja un resultado negativo, es decir, cuando no existe ningún evento de reactivación provocado por dicha fuente [SWS_EcuM_02927].

Uso y parámetros

A través del parámetro de entrada WakeupSource de tipo EcuM_WakeupSourceType se pasa la fuente de activación para la cual debe cancelarse el temporizador de supervisión correspondiente [SWS_EcuM_02927]. La función no devuelve ningún valor (void) y no dispone de parámetros de entrada/salida o de salida [SWS_EcuM_02927].

Modo de funcionamiento y concurrencia

• La función cancela el temporizador CheckWakeupTimer para la fuente de activación especificada; con la cancelación de este temporizador, la comprobación de la fuente de activación se considera concluida [SWS_EcuM_02927].
• La interfaz está definida como síncrona y no reentrante (Non Reentrant) [SWS_EcuM_02927].
• La declaración se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02927].

La función EcuM_CheckRamHash es un callout síncrono y no reentrante (declarado en EcuM_Externals.h) que proporciona una prueba de integridad de la memoria RAM [SWS_EcuM_02921]. La función no tiene parámetros y devuelve un valor de estado del tipo uint8: el valor 0 indica un fallo en la prueba, mientras que cualquier otro valor señala que se ha superado con éxito [SWS_EcuM_02921].

Según [SWS_EcuM_02863], el módulo EcuM llama primero a [SWS_EcuM_02919] antes de detener el microcontrolador y ejecuta EcuM_CheckRamHash tras volver del estado de parada. El objetivo es verificar que el contenido de la RAM haya permanecido consistente incluso tras una fase prolongada de SLEEP [SWS_EcuM_02921].

Para la implementación y la secuencia se aplican las siguientes condiciones de contorno:

• Algoritmo y rango de verificación: La función de prueba es proporcionada por el diseñador del sistema; no tiene que ser exhaustiva, pero debe ejecutarse rápidamente y detectar errores con suficiente fiabilidad [SWS_EcuM_02921]. Las zonas a comprobar deben seleccionarse con cuidado; por regla general, el contenido de la pila (stack) de la tarea en ejecución no se puede verificar [SWS_EcuM_02921].
• Estructura de tareas: Se considera una buena práctica ejecutar la generación y verificación del hash en la misma tarea no interrumpible con una actividad intermedia mínima [SWS_EcuM_02921].
• Multi-Core: En el caso de múltiples núcleos de procesador con EcuM satélite, el callout es invocado exclusivamente por el EcuM maestro y solo comprueba los datos que están dentro de su alcance [SWS_EcuM_02863], [SWS_EcuM_02921].

No se definen mensajes específicos de DET o DEM para este callout; la reacción de error ante un valor de retorno 0 queda presumiblemente a criterio del diseño del sistema de nivel superior [SWS_EcuM_02921]. Pregunta Q-473ef8617db29fe3 (abierta)

La interfaz síncrona EcuM_DisableWakeupSources con el Service-ID 0x44 sirve para configurar las fuentes de activación definidas en el parámetro de campo de bits wakeupSource de tipo EcuM_WakeupSourceType de tal manera que ya no puedan reactivar la ECU [SWS_EcuM_02922]. La firma de la función es void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

Según la especificación, para el contexto de llamada y la integración se aplican las siguientes propiedades:

• Llamador y cabecera: la función es llamada por el módulo ECU Manager y se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02922].
• Parámetros y valores de retorno: como único parámetro de entrada se pasa el campo de bits wakeupSource. La función no posee parámetros de entrada/salida ni de salida, y no devuelve ningún valor de retorno (void) [SWS_EcuM_02922].
• Semántica de ejecución y concurrencia: el procesamiento se realiza de forma síncrona. Además, la función está especificada como no reentrante (Non Reentrant), por lo que deben evitarse las llamadas simultáneas o anidadas [SWS_EcuM_02922].

Con respecto al tratamiento de errores, la especificación para esta llamada a función no contiene ni códigos de error específicos ni notificaciones a DET o DEM [SWS_EcuM_02922].

El callout EcuM_AL_DriverRestart se declara a través del archivo de cabecera EcuM_Externals.h y posee el Service-ID 0x45 [SWS_EcuM_02923]. La función tiene la signatura void EcuM_AL_DriverRestart (void), no requiere parámetros de transferencia y no devuelve ningún valor [SWS_EcuM_02923]. El propósito de esta interfaz es proporcionar la inicialización de controladores así como otras actividades relacionadas con el hardware durante la fase de arranque en caso de despertar (Wakeup Case) [SWS_EcuM_02923].

Para la integración y la interacción con el módulo EcuM se aplican especificaciones vinculantes:

• Para la reinicialización durante la fase WakeupRestart, el integrador debe incorporar un bloque de reinicio (Restart Block) en el código de integración para EcuM_AL_DriverRestart que utilice la lista configurada EcuMDriverRestartList [SWS_EcuM_02947] [SWS_EcuM_02923].
• La lista EcuMDriverRestartList puede contener controladores que actúen como fuentes de despertar (Wakeup Sources) [SWS_EcuM_02562]. En tal caso, EcuM_AL_DriverRestart debe volver a armar (re-arm) el mecanismo de disparo del callback de detección de despertar («wakeup detected») de estos controladores [SWS_EcuM_02562].

En lo que respecta al comportamiento en tiempo de ejecución, la función está definida como síncrona y no reentrante [SWS_EcuM_02923]. Al tratarse de código de integración específico de la aplicación, la especificación no define para esta interfaz códigos de error propios ni mensajes estandarizados a DET o DEM.

La función callout EcuM_StartWakeupSources sirve para iniciar y poner en funcionamiento la(s) fuente(s) de despertar transferida(s), de modo que queden preparadas para la posterior realización de la validación de despertar (Wakeup Validation) [SWS_EcuM_02924].

Uso y contexto de llamada

La función está especificada como una llamada síncrona con el Service-ID 0x46, no tiene valor de retorno (void) y se pone a disposición a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02924].

• Parámetro wakeupSource (in): Pasa la fuente de despertar que se debe iniciar o bien una máscara de bits de varias fuentes de despertar de tipo EcuM_WakeupSourceType a la función callout [SWS_EcuM_02924]. No existen parámetros adicionales de entrada o salida (inout/out) [SWS_EcuM_02924].

Concurrencia y restricciones

En cuanto al entorno de ejecución, EcuM_StartWakeupSources está clasificada como no reentrante (Non Reentrant) [SWS_EcuM_02924]. Por lo tanto, los llamadores deben asegurarse de que la función no se ejecute simultáneamente desde rutinas de servicio de interrupción (ISR) que causen interrupciones o desde tareas paralelas.

Interacción y tratamiento de errores

Dado que EcuM_StartWakeupSources está declarada como un callout, la activación a bajo nivel de hardware de las fuentes afectadas corresponde a la implementación específica de la aplicación realizada por el integrador del sistema [SWS_EcuM_02924]. La especificación no contempla para esta interfaz mensajes de error a DET o DEM ni valores de retorno de error específicos [SWS_EcuM_02924]; por consiguiente, es de suponer que cualquier posible condición de error al iniciar las fuentes deba interceptarse de manera específica para la integración dentro del propio callout. Pregunta Q-b595e7175c34a831 (abierta)

La función EcuM_CheckValidation sirve como interfaz de callout del ECU State Manager para verificar una fuente de activación [SWS_EcuM_02925]. El EcuM invoca esta función para determinar si un evento de activación detectado es válido [SWS_EcuM_02925].

usar

El callout posee el ID de servicio 0x47 y se proporciona a través del archivo de cabecera EcuM_Externals.h [SWS_EcuM_02925]. Como parámetro de entrada sirve wakeupSource de tipo EcuM_WakeupSourceType, mediante el cual se identifica la fuente de activación que se va a validar [SWS_EcuM_02925]. La función no proporciona ningún valor de retorno (void) y no posee parámetros de salida ni de entrada/salida [SWS_EcuM_02925]. La ejecución se realiza de forma síncrona [SWS_EcuM_02925].

Manejo de errores

En la especificación no se definen para este callout códigos de error específicos, valores de retorno en caso de error ni avisos al DET o DEM.

Concurrencia y restricciones

En cuanto a la concurrencia, EcuM_CheckValidation está definida como no reentrante (Non Reentrant) [SWS_EcuM_02925]. El contexto llamador del EcuM debe garantizar que no se produzcan llamadas paralelas o anidadas para la misma fuente de activación o para fuentes diferentes.

Interacción

Si durante la ejecución se ha detectado un evento de activación válido, este debe notificarse obligatoriamente al EcuM a través de la llamada a la función EcuM_ValidateWakeupEvent() [SWS_EcuM_02925]. Interpretación: es de prever que la lógica específica del dispositivo para la comprobación del hardware, así como la decisión sobre la validez, se implementen íntegramente en el código de integración. Pregunta Q-08061e09b474728d (abierta)

La función callout EcuM_StopWakeupSources del módulo EcuM (Classic Platform) sirve para detener de forma dirigida la(s) fuente(s) de despertar transferida(s) tras una validación de despertar no exitosa [SWS_EcuM_02926]. La declaración de esta interfaz síncrona está disponible a través del archivo de cabecera EcuM_Externals.h y lleva el Service-ID 0x48 [SWS_EcuM_02926].

Uso y parámetros de la interfaz:

• Parámetros de entrada: Como único parámetro se pasa wakeupSource de tipo EcuM_WakeupSourceType, que especifica la(s) fuente(s) de despertar que se debe(n) detener [SWS_EcuM_02926].
• Valor de retorno y entradas/salidas: No existen parámetros de entrada/salida (inout) ni parámetros de salida (out) [SWS_EcuM_02926]. La función no devuelve ningún valor (void) a quien la invoca [SWS_EcuM_02926].
• Comportamiento de ejecución: La ejecución de la función está definida como síncrona (Synchronous) [SWS_EcuM_02926].

Concurrencia y tratamiento de errores:

La interfaz está especificada como no reentrante (Non Reentrant) [SWS_EcuM_02926]. Por lo tanto, no se permiten llamadas paralelas y quien la invoca debe evitarlas. La especificación no define para este callout códigos de error específicos, valores de retorno ni notificaciones al módulo Default Error Tracer (DET) o Diagnostic Event Manager (DEM) [SWS_EcuM_02926]. Interpretación: Dado que la función se proporciona como un callout externo a través de EcuM_Externals.h, la desactivación a nivel de hardware del hardware de despertar correspondiente, así como el tratamiento interno de errores, corresponde a la implementación específica del usuario. Pregunta Q-b537c805bed751ab (abierta)

Uso y contexto de llamada

La función EcuM_MainFunction posee la firma void EcuM_MainFunction(void) con el identificador de servicio 0x18 y se proporciona a través del archivo de cabecera SchM_EcuM.h [SWS_EcuM_02837]. No recibe parámetros y no devuelve ningún valor de retorno [SWS_EcuM_02837]. Su cometido consiste en procesar todas las actividades del ECU State Manager mientras el sistema operativo se encuentra en ejecución («OS is up and running») [SWS_EcuM_02837]. Es de suponer que la función se llama típicamente de forma periódica por el programador de tareas (interpretación: integración a través de SchM_EcuM.h). Pregunta Q-ca471f22bdb1f11d (abierta)

Interacción y tareas

Durante el funcionamiento continuo, EcuM_MainFunction asume tareas centrales de coordinación:

• Validación de fuentes de reactivación: Siempre que tras la conclusión de la secuencia WakeupRestart esté disponible una lista de fuentes candidatas de reactivación, el módulo EcuM valida estos candidatos dentro de EcuM_MainFunction [SWS_EcuM_02539].
• Expiración del tiempo de espera de validación: Si expira el tiempo de espera de validación para un evento de reactivación pendiente, la función establece mediante una operación lógica OR el bit correspondiente en la variable interna para eventos de reactivación expirados [SWS_EcuM_04081]. Además, notifica a la gestión BSW a través de BswM_EcuM_Current_Wakeup con una máscara de bits de EcuM_WakeupSourceType del evento y el estado ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Alarm Clock Service: Si el servicio está presente a través de EcuMAlarmClockPresent, el EcuM_MainFunction actualiza el Alarm Clock Timer [SWS_EcuM_04002].

Restricciones e instancias

Como condición de contorno esencial para arquitecturas multinúcleo o multiinstancia, se aplica que EcuM_MainFunction debe ejecutarse en todas las instancias del EcuM [SWS_EcuM_04011].

El tipo de datos EcuM_RunStatusType está definido como uint8 y se proporciona a través del encabezado EcuM.h ([SWS_EcuM_04120]). Sirve para la representación formal del estado actual del protocolo de Run-Request en el ECU Manager y se transmite como resultado al Basic Software Mode Manager (BswM) ([SWS_EcuM_04120]).

El rango de valores admisible comprende tres estados discretos ([SWS_EcuM_04120]):

• ECUM_RUNSTATUS_UNKNOWN (valor 0): Representa un estado desconocido y sirve al mismo tiempo como valor de inicialización definido (Init Value).
• ECUM_RUNSTATUS_REQUESTED (valor 1): Identifica el estado en el que el ECU Manager ha solicitado activamente el estado RUN.
• ECUM_RUNSTATUS_RELEASED (valor 2): Señaliza que el estado RUN ha sido liberado nuevamente por el ECU Manager.

En cuanto a la interacción, el requisito [SWS_EcuM_04121] obliga al módulo ECU Manager a informar de manera vinculante al BswM sobre el estado actual del protocolo de Run-Request mediante los valores de estado indicados en EcuM_RunStatusType. Interpretación: Dado que el requisito no menciona ninguna signatura de función específica o convención de llamada para el flujo de mensajes, la información de estado suele transferirse típicamente al módulo BswM mediante una función de notificación interna o una interfaz de callback. Pregunta Q-e136b90c2edbc29c (abierta) No se contemplan códigos de error específicos, mensajes DET o DEM ni condiciones especiales de reentrancia para este tipo de datos elemental en los requisitos presentes.

El tipo de datos EcuM_WakeupStatusType describe, según [SWS_EcuM_04041], los estados posibles de una fuente de despertar (Wakeup Source) en el ECU State Manager. El tipo se deriva del tipo básico uint8 y se proporciona a través del encabezado EcuM.h [SWS_EcuM_04041].

El rango de valores representa el ciclo de vida de un evento de despertar a través de cuatro estados [SWS_EcuM_04041]:

• ECUM_WKSTATUS_NONE (valor 0): no se ha detectado ningún evento de despertar pendiente [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (valor 1): se ha detectado un evento de despertar, pero aún no se ha validado [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (valor 2): el evento de despertar es válido y se ha confirmado correctamente [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (valor 3): el evento de despertar no se validó a tiempo y, por consiguiente, ha expirado [SWS_EcuM_04041].

Uso e interacción: el tipo sirve como representación de estado central para fuentes de despertar. Interpretación: es de suponer que los invocadores evalúen este estado en el marco de consultas de estado para determinar si una fuente de despertar se está validando activamente, si ya ha señalizado un despertar válido o si se ha superado la ventana de tiempo de validación. Pregunta Q-a3f721e8f1753eb1 (abierta)

El tipo EcuM_StateType es un tipo de datos derivado de uint8 que se proporciona a través de la cabecera EcuM.h y reproduce los estados operativos del ECU State Manager [SWS_EcuM_91005]. El módulo EcuM tiene la obligación de definir todos los estados indicados en EcuM_StateType [SWS_EcuM_02664]. El rango de valores comprende la máscara de subestados ECUM_SUBSTATE_MASK (0x0f), así como los estados principales ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40) y ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Uso e interacción

El tipo de datos actúa como parámetro central para la comunicación de estados entre el BswM y el EcuM:

• Cambio de estado a EcuM: A través de la llamada de función síncrona y reentrante EcuM_SetState(EcuM_StateType state) con el Service ID 0x2b, el BswM notifica al módulo EcuM sobre un cambio de estado [SWS_EcuM_04122].
• Notificación de estado a BswM: El EcuM notifica el estado actual al BswM mediante la llamada a la interfaz BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Concurrencia, orden y tratamiento de errores

En cuanto al orden temporal, rige el requisito de que el EcuM solo puede establecer un nuevo estado una vez que la RTE haya emitido su confirmación a través del correspondiente puerto de acuse de recibo (Acknowledgement) [SWS_EcuM_04143]. En las fuentes disponibles no están previstos códigos de error específicos, valores de retorno o notificaciones DET/DEM para este tipo de datos.

El tipo EcuM_Mode está definido como ModeDeclarationGroup de acuerdo con [SWS_EcuM_04107] y representa los estados centrales del ECU State Manager. Se establece STARTUP como modo inicial. Además, el grupo incluye los modos definidos POST_RUN, RUN, SHUTDOWN y SLEEP [SWS_EcuM_04107].

En el conjunto del sistema, EcuM_Mode sirve como base de tipo para el grupo de modos currentMode dentro de la interfaz de servicio EcuM_CurrentMode [SWS_EcuM_04108]. Mediante esta interfaz se puede consultar el modo actual de la ECU o señalizarlo a otros componentes de software a través del mecanismo de modos de la RTE.

En cuanto al contexto de invocación y la concurrencia, la especificación del propio tipo no contiene restricciones explícitas relativas a reentrada o códigos de error; la gestión de las transiciones de estado se realiza a través de las correspondientes interfaces de servicio del EcuM.

El elemento currentMode está definido como Provided-Port del módulo EcuM y proporciona el Service Interface EcuM_CurrentMode para la arquitectura de software [SWS_EcuM_04112]. Este Service Interface sirve para leer el modo actual de la ECU y encapsula el grupo de modos currentMode sobre la base del tipo de datos EcuM_Mode [SWS_EcuM_04108].

Durante el funcionamiento continuo del sistema, su uso sirve para señalizar cambios de estado:

• Llamada y uso: Tan pronto como se produce un cambio de modo, el EcuM lo notifica a través de puertos de modo de la RTE a los componentes de software (SW-Cs) [SWS_EcuM_04133]. Bajo la asunción de especificación del nombre de puerto currentMode y utilizando la direct RTE-API, se llama para ello a la función Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) [SWS_EcuM_04133].
• Parámetros y valor de retorno: El parámetro mode transfiere el nuevo modo que se va a adoptar a la RTE [SWS_EcuM_04133]. El valor de retorno del tipo Rte_StatusType proporcionado por la Switch-API no se evalúa, sino que según la especificación debe ignorarse obligatoriamente [SWS_EcuM_04133].
• Interacción: Un componente de software que deba ser informado sobre cambios de modo debe solicitar la interfaz de switch de modo EcuM_CurrentMode como Required-Port [SWS_EcuM_04133].

Uso y rango de valores

El tipo de datos EcuM_ShutdownModeType se basa en uint16 y se proporciona a través del archivo de cabecera Rte_EcuM_Type.h [SWS_EcuM_04101]. Representa los modos configurados en el ECU State Manager. Su rango de valores abarca:

• los modos de reposo configurados según EcuMSleepModeId [SWS_EcuM_04101], así como
• los modos de reinicio configurados, calculados a partir del desplazamiento 256 + EcuMResetModeId [SWS_EcuM_04101].

Interacción y contexto de llamada

El tipo se utiliza en servicios síncronos y reentrantes del ECU Manager:

• EcuM_SelectShutdownTarget adopta shutdownMode como parámetro de entrada para definir el modo Sleep concreto (en caso del objetivo ECUM_SHUTDOWN_TARGET_SLEEP) o el mecanismo de reinicio (en caso del objetivo ECUM_SHUTDOWN_TARGET_RESET) [SWS_EcuM_02822].
• EcuM_GetShutdownTarget devuelve, a través de un parámetro de tipo puntero a EcuM_ShutdownModeType, qué modo configurado de Sleep o de reinicio está seleccionado para el objetivo de shutdown actual [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget emite el modo de shutdown del proceso de shutdown precedente a través de un parámetro de salida [SWS_EcuM_02825]. A través del Service Interface EcuM_ShutdownTarget, esta funcionalidad también está a disposición de los componentes de software (SW-Cs) [SWS_EcuM_03011].

Tratamiento de errores y condiciones límite

Las funciones devuelven Std_ReturnType. Si, por ejemplo, se pasa un puntero NULL a EcuM_GetShutdownTarget o EcuM_GetLastShutdownTarget, la llamada falla con E_NOT_OK [SWS_EcuM_02824], [SWS_EcuM_02825]. En caso de ejecución correcta, los servicios notifican E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].