ECU State Manager (EcuM)

The synchronous and reentrant function EcuM_GoDownHaltPoll instructs the ECU State Manager module to transition into a sleep mode, a reset, or the OFF state depending on the previously selected shutdown target [SWS_EcuM_91002]. It is available via the header file EcuM.h and has the service ID 0x2c [SWS_EcuM_91002].

Parameters and call authorization

UserID of type EcuM_UserType is passed as the sole input parameter. This identifies the calling user. Calling is strictly regulated: Only preconfigured users may execute this function [SWS_EcuM_91002].

Return values and execution behavior

The return behavior largely depends on the type of shutdown target set [SWS_EcuM_91002]:

• E_NOT_OK: The request was not accepted [SWS_EcuM_91002].
• E_OK: If the target is SLEEP, the function returns successfully with this status after leaving the sleep state [SWS_EcuM_91002].
• No return: If RESET or OFF was selected as the shutdown target, the function call no longer returns to the caller [SWS_EcuM_91002].

Restrictions and Error Handling

Although the function is formally declared as reentrant, its intended execution requires the prior definition of a valid shutdown target [SWS_EcuM_91002]. Specific DET or DEM error codes are not listed in the interface specification; a failure or rejection of the request is indicated directly via the return value E_NOT_OK [SWS_EcuM_91002].

The synchronous service function EcuM_Init initializes the ECU State Manager and initiates the orderly startup sequence of the ECU ([SWS_EcuM_02811]). It is declared via the header EcuM.h with the service ID 0x01, takes no parameters, and returns no return value ([SWS_EcuM_02811]). Formally classified as reentrant, EcuM_Init never returns to the caller after being called because it transfers execution to the operating system by calling StartOS ([SWS_EcuM_02811]).

As part of its execution, the function processes the defined StartPreOS sequence and its activities in the exact specified order ([SWS_EcuM_02411], [SWS_EcuM_02684]). An essential component of this phase is checking the configuration consistency: Within EcuM_Init, the module checks whether the corresponding structure field is identical to the value of ECUM_CONFIGCONSISTENCY_HASH ([SWS_EcuM_02798]).

In addition, EcuM_Init controls the initialization of the drivers on multicore systems ([SWS_EcuM_04145]). The function calls the callouts EcuM_AL_DriverInitZero and EcuM_AL_DriverInitOne on each individual core ([SWS_EcuM_04145]). For the callout implementations, the requirement applies to ensure that on the respective active core, only those MCAL modules are initialized that are actually executed on this core ([SWS_EcuM_04145]).

The synchronous and non-reentrant function EcuM_StartupTwo implements the STARTUP II state of the ECU State Manager [SWS_EcuM_02838]. The interface is declared via the header file EcuM.h and has the service ID 0x1a [SWS_EcuM_02838]. According to the function signature void EcuM_StartupTwo(void), the call accepts neither input parameters nor input/output or output parameters and returns no return value to the caller [SWS_EcuM_02838].

When the ECU Manager module is activated by the function EcuM_StartupTwo, it executes the actions of the StartPostOS sequence [SWS_EcuM_02932].

Essential requirements exist for integration regarding the call context and concurrency: The function must imperatively be called from a task that is started directly as a consequence of StartOS [SWS_EcuM_02806]. This requires that the call of EcuM_StartupTwo takes place either from an autostart task or from a task that is explicitly started [SWS_EcuM_02806]. Since the function is specified as non-reentrant, no concurrent or multiple calls may take place [SWS_EcuM_02838].

The synchronous service function EcuM_Shutdown (service ID 0x02) is provided via the header file EcuM.h and takes over execution control for carrying out the activities of the "GO OFF II" phase [SWS_EcuM_02812]. It serves for the final termination of the shutdown process [SWS_EcuM_02953].

Call Context and Semantics

Typically, the function is called from the shutdown hook [SWS_EcuM_02812]. According to the requirements, this hook is explicitly obligated to call EcuM_Shutdown in order to terminate the shutdown procedure [SWS_EcuM_02953].

• Signature: void EcuM_Shutdown(void) with service ID 0x02 [SWS_EcuM_02812].
• Parameters: Neither input nor output nor input/output parameters exist [SWS_EcuM_02812].
• Return value: The interface does not return a return value [SWS_EcuM_02812].
• Synchronicity: The call is executed synchronously [SWS_EcuM_02812].

Concurrency and Control Flow

In the specification, EcuM_Shutdown is declared as reentrant [SWS_EcuM_02812]. For the program flow, however, the strict requirement applies that EcuM_Shutdown must not return to the caller [SWS_EcuM_02953]. After execution, the function shuts down the ECU permanently or alternatively triggers a reset [SWS_EcuM_02953].

Usage and Call Context

The synchronous function EcuM_SetState serves the BswM to notify the EcuM of a state change [SWS_EcuM_04122]. The input parameter passed is state of type EcuM_StateType, which specifies the state predetermined by the BswM [SWS_EcuM_04122]. The function has no return value [SWS_EcuM_04122].

Functional principle and interaction

When called, the function sets the internal state of the EcuM to the value of parameter state [SWS_EcuM_04123]. If the BswM sets a state of the EcuM in this way, the EcuM indicates the corresponding mode to the RTE [SWS_EcuM_04116].

Error handling

If the passed value of parameter state is invalid, EcuM_SetState does not change the EcuM state [SWS_EcuM_04123]. If development error reporting is enabled, the function additionally reports the error ECUM_E_STATE_PAR_OUT_OF_RANGE to the DET module in this error case [SWS_EcuM_04123].

Concurrency and interface

Execution is synchronous and reentrant [SWS_EcuM_04122]. The service is declared via the header file EcuM.h [SWS_EcuM_04122].

use

The synchronous and reentrant function EcuM_RequestRUN serves to request the RUN state from the ECU State Manager [SWS_EcuM_04124]. The identifier of the requesting entity is passed as a parameter via user of type EcuM_UserType; only users that have already been made known to the state manager at configuration time are authorized [SWS_EcuM_04124]. The function returns E_OK if the EcuM accepted the request, otherwise E_NOT_OK [SWS_EcuM_04124]. The service is declared via the header EcuM.h [SWS_EcuM_04124].

Error Handling and Restrictions

Requests must not be nested: A single user can hold at most one active RUN request at a time [SWS_EcuM_04125]. If EcuM_RequestRUN detects repeated or duplicate calls by the same user, the error code ECUM_E_MULTIPLE_RUN_REQUESTS is reported to the DET if development error detection is enabled [SWS_EcuM_03024], [SWS_EcuM_04125].

Interaction

Each state request successfully set with EcuM_RequestRUN must be released again after completion of the activity. For this purpose, the complementary, likewise synchronous and reentrant service EcuM_ReleaseRUN is available, to which the same user ID is passed [SWS_EcuM_04127].

use

The synchronous function EcuM_ReleaseRUN (service ID 0x04) serves to release a RUN state request previously registered via EcuM_RequestRUN [SWS_EcuM_04127]. The interface is provided via header EcuM.h and is primarily intended for the implementation of AUTOSAR ports [SWS_EcuM_04127]. As an input parameter, the function expects the user identifier user of type EcuM_UserType, which uniquely identifies the releasing entity within the module [SWS_EcuM_04127].

The return value of type Std_ReturnType signals with E_OK that the release request was successfully accepted by the module [SWS_EcuM_04127]. If the release could not be processed, the service returns the error value E_NOT_OK [SWS_EcuM_04127].

Error Handling and Concurrency

Specific error codes, development errors (DET), or production errors (DEM) are not listed in the specification; the rejection of a request manifests exclusively via the return of E_NOT_OK [SWS_EcuM_04127]. It is to be assumed (Interpretation:) that a return of E_NOT_OK presumably occurs when there is no active request for the specified user ID or an invalid parameter value was passed. Question Q-cbe9031cffe1be81 (open)

The function is declared as reentrant and may therefore be called in concurrent execution contexts [SWS_EcuM_04127]. As a functional sequencing constraint, the call strictly requires that the corresponding user has previously requested the state via EcuM_RequestRUN [SWS_EcuM_04127].

Interaction

The EcuM module provides this service to terminate holding the RUN state via defined ports [SWS_EcuM_04127]. For RTE configuration and interaction with local RTE runtime behavior, the specification defines the internal behavior of the EcuStateManager with multiple concurrently executable runnable entities [SWS_EcuM_03018].

use

The synchronous function EcuM_RequestPOST_RUN serves to request the POST RUN state from the ECU State Manager ([SWS_EcuM_04128]). The caller identifies itself via the parameter user, whereby each requesting entity must have already been made known to the state manager at configuration time ([SWS_EcuM_04128]). The service is declared in the header EcuM.h, intended for the implementation of AUTOSAR ports, and acknowledges successful acceptance with E_OK or rejection with E_NOT_OK ([SWS_EcuM_04128]).

Error handling

If the detection of development errors is enabled, a repeated call by the same user causes EcuM_RequestPOST_RUN to report the error ECUM_E_MULTIPLE_RUN_REQUESTS to the DET ([SWS_EcuM_03025]). Interpretation: In the case of such multiple requests or with invalid user IDs, the service would presumably respond with E_NOT_OK ([SWS_EcuM_04128]). Question Q-b5bbd7d5b53e76ba (open)

Concurrency and Interaction

The function is designed to be reentrant ([SWS_EcuM_04128]). In the module, the requests for RUN and POST RUN must be tracked strictly independently of each other via two separate variables ([SWS_EcuM_04128]). Each request registered via this service keeps the POST RUN state active until it is explicitly revoked again by the complementary call of EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]).

Usage and Semantics

The synchronous and reentrant function EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) serves to release a POST-RUN request previously set via EcuM_RequestPOST_RUN. The identifier of the entity that releases the POST-RUN status is passed via input parameter user of type EcuM_UserType. The interface is available via header file EcuM.h and is primarily designed for realizing AUTOSAR ports ([SWS_EcuM_04129]).

Return Values and Error Handling

The function returns the status Std_ReturnType ([SWS_EcuM_04129]):

• E_OK: The release request was successfully accepted by the ECU State Manager.
• E_NOT_OK: The release request was rejected. Interpretation: A rejection with E_NOT_OK is likely to occur if no active request was registered for the specified user or an invalid user identifier was passed. Question Q-67bd8594612defca (open)

Concurrency and Interaction

The service is specified as reentrant ([SWS_EcuM_04129]), so that concurrent calls by multiple entities are permissible. The function is part of the internal behavior of module EcuM ([SWS_EcuM_03018]). The call logically requires that the entity has previously requested the POST RUN phase ([SWS_EcuM_04129]). Interpretation: The call is typically expected to occur from software components via RTE ports as soon as their post-run activities before shutdown are completed. Question Q-81f71656d4debb4a (open)

The synchronous service function EcuM_SelectShutdownTarget serves to select the shutdown target for the ECU and is provided via the header file EcuM.h as well as part of the port interface of the ECU Manager module [SWS_EcuM_02822]. Calling it sets the internal shutdown target to the value of the passed parameter shutdownTarget [SWS_EcuM_00624].

The function expects two input parameters [SWS_EcuM_02822]:

• shutdownTarget: Determines the selected shutdown target [SWS_EcuM_02822].
• shutdownMode: Contains the identifier of a sleep mode (if the target is ECUM_SHUTDOWN_TARGET_SLEEP) or a reset mechanism (if the target is ECUM_SHUTDOWN_TARGET_RESET) according to configuration [SWS_EcuM_02822].

The call does not trigger any immediate setup or execution activities, but merely stores the values for later use in phase SHUTDOWN or SLEEP [SWS_EcuM_02585].

Regarding concurrency, the function is specified as reentrant [SWS_EcuM_02822]. In the RTE internal behavior of the ECU State Manager, the corresponding runnable entity SelectShutdownTarget is declared with canbeInvokedConcurrently = TRUE [SWS_EcuM_03018], which permits parallel calls.

The return value of type Std_ReturnType signals with E_OK that the new shutdown target was successfully set, and with E_NOT_OK that the adoption failed [SWS_EcuM_02822]. The specification does not mention concrete error causes for E_NOT_OK or DET reports at this point; presumably, invalid or unconfigured combinations of target and mode lead to rejection. Question Q-e916f3a6ac0bf47e (open)

The synchronous function EcuM_SelectShutdownCause serves to select the cause for a shutdown of the ECU and is available via the header file EcuM.h [SWS_EcuM_04050].

Usage and semantics:

• Parameters: The input parameter target of type EcuM_ShutdownCauseType passes the selected shutdown cause [SWS_EcuM_04050].
• Return value: A return value of type Std_ReturnType signals with E_OK that the new cause was successfully set, and with E_NOT_OK that setting failed [SWS_EcuM_04050].
• Execution: The service operates synchronously under the service ID 0x1b and is specified as reentrant [SWS_EcuM_04050].

Concurrency and Interaction:

The function is part of the port interface of the ECU Manager module [SWS_EcuM_04050]. For the configuration of the local RTE, the runnable entity SelectShutdownCause with the symbol EcuM_SelectShutdownCause is defined in the internal behavior EcuStateManager, where the property canbeInvokedConcurrently = TRUE is assigned [SWS_EcuM_03018].

Error handling:

No specific DET or DEM messages are identified within the scope of the specification; error states when setting the cause are indicated exclusively via the return value E_NOT_OK [SWS_EcuM_04050].

The synchronous service function EcuM_ClearWakeupEvent (service ID 0x16) serves to reset wakeup events and is available via the header file EcuM.h [SWS_EcuM_02828]. As a parameter, it takes the bitmask sources of type EcuM_WakeupSourceType and has no return value [SWS_EcuM_02828].

Upon being called, all pending events set as bits in sources are cleared from three internal variables of the module [SWS_EcuM_02683]:

• from the internal variable for pending wakeup events (pending wakeup events),
• from the internal variable for validated wakeup events (validated events), and
• from the internal variable for expired wakeup events (expired events) [SWS_EcuM_02683].

Regarding the call context, EcuM_ClearWakeupEvent may be called flexibly from the interrupt context, from the regular OS context, as well as from an OS-free context [SWS_EcuM_02807]. At the same time, however, the function is mandatorily specified as non-reentrant (Non-Reentrant) and non-interruptible (Non-Interruptible) [SWS_EcuM_02828]. Interpretation: Since the function is permitted in different contexts but is non-interruptible, the integrator or caller is likely required to ensure organizationally that no concurrent or mutually interrupting calls take place. Question Q-71a4b1b218505a1c (open)

The synchronous function EcuM_AbortWakeupAlarm serves to cancel a wakeup alarm previously set by a user [SWS_EcuM_04061]. The interface is available via the header file EcuM.h and forms part of the port interface of the ECU Manager module [SWS_EcuM_04061].

Parameters and Return Values

• user (In): Identifier of the user of type EcuM_UserType who wishes to cancel the wakeup alarm [SWS_EcuM_04061]. Input/output or pure output parameters do not exist [SWS_EcuM_04061].
• E_OK: The service was executed successfully and the alarm was canceled [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE: No active alarm belonging to the passed user was found [SWS_EcuM_04061].
• E_NOT_OK: Execution of the service failed [SWS_EcuM_04061].

Concurrency and Interaction

The function has the service ID 0x24 and is specified as reentrant [SWS_EcuM_04061]. Calls can thus take place concurrently for different users. The internal behavior of the ECU Manager defines the executable entities for configuring the local RTE [SWS_EcuM_03018]; as part of the module port interface, the call is typically expected to be initiated by software components via the RTE. Question Q-2c8f004d9f00bbd3 (open)

According to [SWS_EcuM_04064], the synchronous and reentrant function EcuM_SetClock serves to set the internal time of the ECU State Manager to a predetermined value. As part of the port interface of the ECU Manager, the function can be included and called via the header file EcuM.h [SWS_EcuM_04064].

The main application purpose of the interface is testing alarm services: alarms whose regular expiration would take days can be verified in test operation by deliberately setting the time [SWS_EcuM_04064]. In doing so, two input parameters are passed:

• user (type EcuM_UserType): Identifier of the caller or user wishing to set the time.
• time (type EcuM_TimeType): Absolute time specification in seconds since connecting the battery (Battery Connect).

As a return value, the service returns the status Std_ReturnType with E_OK upon successful execution or E_NOT_OK in case of error [SWS_EcuM_04064]. Concrete error causes or DET messages are not specified at the interface; presumably, passing unauthorized user IDs or invalid time values leads to the return of E_NOT_OK. Question Q-248768580c0309e8 (open)

With regard to the internal module behavior and the RTE configuration, the function integrates into the structure of the runnable entities of the EcuStateManager [SWS_EcuM_03018].

The synchronous function EcuM_SelectBootTarget serves to select a boot target for the ECU and is part of the port interface of the ECU Manager as well as available via the header EcuM.h [SWS_EcuM_02835]. The desired target is passed via the input parameter target of type EcuM_BootTargetType [SWS_EcuM_02835].

As a return value, the function signals E_OK if the new boot target was accepted by the EcuM, otherwise E_NOT_OK [SWS_EcuM_02835]. The implementation must store the selected target in a manner that is compatible with the bootloader [SWS_EcuM_02247]. The currently set value can be queried via the complementary service EcuM_GetBootTarget [SWS_EcuM_02836].

The function is specified as reentrant [SWS_EcuM_02835]; within the internal behavior for the RTE configuration, the runnable entity SelectBootTarget is declared with canbeInvokedConcurrently = TRUE [SWS_EcuM_03018]. As a restriction, this service is intended exclusively for software components (SW-Cs) related to diagnostics or boot management and may depend on the specifically deployed bootloader [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent is a synchronous service (service ID 0x14) that signals to the ECU Manager that the wakeup sources passed in parameter sources have been successfully validated ([SWS_EcuM_02829]). After wakeup, the ECU State Manager waits for this confirmation in the validation sequence. Upon being called, the function stops the running timeout timer of the validation ([SWS_EcuM_02710]) and enters the passed events into the internal variable for validated wakeup events by ORing the bitmask ([SWS_EcuM_04078]).

The function is reentrant ([SWS_EcuM_02829]) and may be called from both the task and the interrupt context ([SWS_EcuM_02345]). If the ECU Manager is in the state RUN, the call remains without effect for all wakeup sources, provided they are not communication channels ([SWS_EcuM_02790]). For sources assigned to a communication channel, by contrast, the service takes full effect in every phase of the ECU ([SWS_EcuM_02791]).

In the overall sequence, the service interacts closely with wakeup validation and communication management:

• Validation Check: For checking, the ECU Manager calls the callout EcuM_CheckValidation; if a valid wakeup event is detected, feedback is provided via EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Configuration: If no validation protocol is configured for a wakeup source (EcuMValidationTimeout), EcuM_SetWakeupEvent already implies calling EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Notification: If EcuMComMChannelRef is configured for the wakeup source, the service calls ComM_EcuM_WakeUpIndication ([SWS_EcuM_02645]). If EcuMComMPNCRef is configured, ComM_EcuM_PNCWakeUpIndication is additionally triggered for each referenced PNC ([SWS_EcuM_04140]).

The synchronous and non-reentrant callback function EcuM_ErrorHook (provided via EcuM_Externals.h) is called by the ECU State Manager as soon as severe errors occur that make regular further processing impossible and require stopping the ECU [SWS_EcuM_02904]. Via the parameter reason, the specific error cause is transmitted [SWS_EcuM_02904].

The defined error causes include ECUM_E_RAM_CHECK_FAILED and ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. If the RAM check fails during wakeup, the ECU Manager is obliged to trigger EcuM_ErrorHook with the reason ECUM_E_RAM_CHECK_FAILED [SWS_EcuM_02987]. In addition, error handling is performed via this hook if a call to an operating system function fails and no other error reaction is specified; in this case, the EcuM remains in the previous state [SWS_EcuM_04139].

The following constraints apply to the system integrator during implementation:

• ECU Stop Modality: The integrator chooses the manner in which the ECU is shut down (e.g. reset, halt, restart, or safe state) [SWS_EcuM_02904]. Interpretation: In the case of drastic measures such as a reset or halt, the function is typically not expected to return to regular control flow. Question Q-59c23e3a2569f670 (open)
• Error Notification to the DEM: It is at the discretion of the integrator whether the error is forwarded to the DEM, provided it is ensured that the DEM does not write to corrupt NVRAM blocks [SWS_EcuM_02987].

Usage and Call Conditions

The callout function EcuM_AL_SetProgrammableInterrupts is called by the module ECU State Manager to configure and set the corresponding interrupts on ECUs with programmable interrupt controllers [SWS_EcuM_04085]. However, execution of this callout only takes place if the configuration parameter EcuMSetProgrammableInterrupts is set to the value true [SWS_EcuM_04085]. If this parameter is not enabled, the call is omitted [SWS_EcuM_04085]. For integrators and platform drivers, the declaration of the interface is provided via the header file EcuM_Externals.h [SWS_EcuM_04085].

The interface has the syntax void EcuM_AL_SetProgrammableInterrupts (void) and is assigned to the service ID 0x4A [SWS_EcuM_04085]. The call is completely parameterless: Neither input, input/output, nor output parameters are passed, and the function returns no return value to the calling module [SWS_EcuM_04085].

Concurrency and Limitations

For EcuM_AL_SetProgrammableInterrupts, an asynchronous execution behavior (Asynchronous) is defined in the specification [SWS_EcuM_04085]. Regarding concurrency, the function is classified as non-reentrant (Non Reentrant) [SWS_EcuM_04085]. For integration, this means that parallel or nested calls to the interface are inadmissible and the interrupt-related configuration must run without concurrent reentrancy [SWS_EcuM_04085].

use

The callout function EcuM_AL_DriverInitZero (service ID 0x31) is called synchronously, has neither parameters nor a return value, and is non-reentrant [SWS_EcuM_02905]. It is declared via the header EcuM_Externals.h [SWS_EcuM_02905]. The function serves to provide early driver initializations as well as fundamental hardware-related startup activities that are strictly necessary in order to subsequently load the post-build configuration data [SWS_EcuM_02905].

Constraints and Multicore Operation

Specific specifications and restrictions apply to the implementation and execution:

• Configuration classes: At this early stage, only modules that are configurable as pre-compile or link-time may be used [SWS_EcuM_02905]. Post-build-configurable drivers are not yet available here.
• Call context: The function is called by EcuM_Init on each Core of the system [SWS_EcuM_04145].
• Core-specific initialization: The implementation of the callout must ensure that on the currently active Core, only those MCAL modules are initialized that are actually executed on this specific Core [SWS_EcuM_04145].

Return values, specific error codes, or notifications via DET or DEM are not defined for this callout [SWS_EcuM_02905].

The function EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) is a synchronous callout of the ECU State Manager that is provided via the header file EcuM_Externals.h and has the service ID 0x32. The interface has no input, output, or input/output parameters ([SWS_EcuM_02906]). Its central purpose is to determine during the startup process, based on hardware or memory conditions, which post-build configuration data set shall be used for the further course of system startup ([SWS_EcuM_02906]).

To determine the configuration, the callout shall evaluate external or resident criteria such as the status of a port pin or a value in NVRAM ([SWS_EcuM_02906]). Subsequently, the function must load this configuration data into a memory segment that all BSW modules can access ([SWS_EcuM_02906]). As a return value, it returns a pointer of type const EcuM_ConfigType* to the EcuM post-build configuration ([SWS_EcuM_02906]). This pointer forms the common starting point for the entire BSW, since the structure contains pointers to the respective post-build configurations of all other BSW modules ([SWS_EcuM_02906]).

Regarding calling behavior, the function is specified as synchronous and non-reentrant (Non Reentrant) ([SWS_EcuM_02906]). Specific error codes, special error return values, as well as interfaces to DET or DEM are not defined for this callout ([SWS_EcuM_02906]). It should therefore be considered an interpretation of the requirements that an application-specific callout implementation must handle error states independently, since the absence of a valid configuration pointer would presumably prevent orderly startup of the dependent BSW modules. Question Q-b9487647fb39a2e2 (open)

Usage and Semantics

The function EcuM_AL_DriverInitOne is a callout function of the ECU State Manager (EcuM), which is provided via the header file EcuM_Externals.h [SWS_EcuM_02907]. Its primary task is to perform the initialization of drivers as well as further hardware-related startup activities of the control unit in the event of a power-on reset [SWS_EcuM_02907]. Since this is a callout, the actual implementation of the hardware and driver initialization is likely performed by the respective system integrator. Question Q-e22baf2fa31cf075 (open)

The interface has the C signature void EcuM_AL_DriverInitOne (void) and is assigned to the service ID 0x33 [SWS_EcuM_02907]. It accepts no input parameters and also returns no return value to the caller [SWS_EcuM_02907].

Concurrency and Limitations

According to [SWS_EcuM_02907], the following boundary conditions apply to the call and runtime behavior:

• Synchronism: Execution is synchronous (Synchronous), so the caller waits for the startup activities to complete.
• Reentrancy: The function is defined as non-reentrant (Non Reentrant); concurrent or interrupting multiple calls are not permitted.
• Call context: Activation is specified exclusively for the initialization phase immediately after a power-on reset.

Error handling

Since EcuM_AL_DriverInitOne has the return type void, there is no direct feedback regarding success or failure of the initialization at the interface level [SWS_EcuM_02907]. Specific error codes, DET, or DEM messages are not defined for this callout in the present specification scope.

The function EcuM_LoopDetection is a callout of the ECU State Manager with the service ID 0x4B, which is provided via the header file EcuM_Externals.h [SWS_EcuM_04137].

Usage and Call Context

If the configuration parameter EcuMResetLoopDetection is set to true, this callout is called synchronously at each startup [SWS_EcuM_04137]. The function has neither input, input/output, nor output parameters and returns no return value (signature: void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Concurrency and Limitations

Execution of EcuM_LoopDetection is specified as synchronous and non-reentrant (Non Reentrant) [SWS_EcuM_04137]. Since this is a callout, the concrete implementation of the loop detection is typically the responsibility of the integrator or user to detect repeated reset loops during system startup.

use

The function EcuM_OnGoOffOne serves to announce the reaching of the system state GO OFF I and to give the system designer the opportunity to take appropriate measures immediately before the transition [SWS_EcuM_02916]. The function is executed synchronously, expects no passed parameters (neither in nor inout), and returns no return value (void) [SWS_EcuM_02916]. Since the interface is declared via the header file EcuM_Externals.h, it is plausibly a user-specific callout function implemented in the integration code [SWS_EcuM_02916]. Question Q-93de53c47a5a6142 (open)

Error handling

In the specification for EcuM_OnGoOffOne, neither development errors (DET) nor production errors (DEM) or specific error return values are listed [SWS_EcuM_02916]. From this it can be concluded that the caller does not expect standardized error management and any exceptional cases must be handled autonomously within the user-specific implementation [SWS_EcuM_02916].

Concurrency and Limitations

The following properties are defined for the call context and runtime behavior [SWS_EcuM_02916]:

• Reentrancy: The function is specified as non-reentrant (Non Reentrant) and must under no circumstances be called in parallel or nested [SWS_EcuM_02916].
• Synchronicity: The semantics are strictly synchronous (Synchronous), so that the caller waits for the complete return of the function [SWS_EcuM_02916].
• Service ID: The service is represented internally by the hexadecimal identifier 0x3C [SWS_EcuM_02916].

Due to the synchronous behavior and the impending transition into the GO OFF I state, it can be assumed that blocking operations should be avoided so as not to impermissibly delay the shutdown or transition process [SWS_EcuM_02916]. Question Q-93f5e23c581f0c38 (open)

According to the specification, the synchronous function EcuM_OnGoOffTwo serves to allow the system designer to be notified that the GO OFF II state is imminent [SWS_EcuM_02917]. The call takes place parameterless without in, inout, or out parameters and returns no return value to the caller [SWS_EcuM_02917].

With regard to execution context and concurrency, the interface is assigned the service ID 0x3D and specified as non-reentrant (Non Reentrant) [SWS_EcuM_02917]. It is provided via the header EcuM_Externals.h [SWS_EcuM_02917]. Interpretation: Since the declaration is located in EcuM_Externals.h and serves to notify the system designer, the function is likely designed as a synchronous callout of the ECU management that is called prior to transitioning to the GO OFF II state. Question Q-bb0ae6e4632de827 (open)

Due to the property as a non-reentrant interface, the call must not be repeated concurrently or interrupting [SWS_EcuM_02917]. Specific error codes, notifications to DET or DEM, and separate error handling mechanisms are not defined in the specification scope [SWS_EcuM_02917].

use

The callout function EcuM_AL_SwitchOff is part of the ECU State Manager (EcuM) module and serves to hold the user-specific code for switching off the power supply of the ECU [SWS_EcuM_02920]. The interface is defined as synchronous, has the service ID 0x3E, and is provided via the header file EcuM_Externals.h [SWS_EcuM_02920].

According to the specification, the function accepts neither input, input/output, nor output parameters and has no return value (void) [SWS_EcuM_02920]. If the ECU hardware cannot power itself down, the specification provides that triggering a reset can instead represent an adequate response [SWS_EcuM_02920].

Interaction and Concurrency

The call of EcuM_AL_SwitchOff is performed mandatorily by the module ECU Manager as soon as the selected shutdown target is OFF [SWS_EcuM_04075]. Regarding concurrency behavior, the callout is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02920]. Interpretation: Since the objective of the function is the complete disconnection of the power supply or alternatively a reset, this callout likely represents the final step of the shutdown sequence, after which no further regular program execution takes place. Question Q-e8a1aaa1413bbea9 (open)

Error handling

Neither specific error codes nor error handling mechanisms or messages to DET or DEM are provided for the callout in the specification [SWS_EcuM_02920].

The callout EcuM_AL_Reset serves to hold the integration-specific code responsible for resetting the ECU ([SWS_EcuM_04065]). The interface is declared via the header file EcuM_Externals.h and has the service ID 0x4C ([SWS_EcuM_04065]).

The function is called synchronously and is defined as non-reentrant (Non Reentrant) ([SWS_EcuM_04065]). As the only input parameter, reset of type EcuM_ResetType is passed, which specifies the concrete type of reset to be performed ([SWS_EcuM_04065]). The function has no return value (void) and has no parameters for output or input/output ([SWS_EcuM_04065]).

In the interaction of the shutdown phase, it is specified that the module ECU Manager must mandatorily call the callout EcuM_AL_Reset when the target of the shutdown is set to RESET ([SWS_EcuM_04074]). Neither error codes nor notifications to DET or DEM are provided for the callout in the specification ([SWS_EcuM_04065]). Interpretation: The callout is likely to execute hardware-related control commands that directly cause the MCU to reset. Question Q-1e318404843faabd (open)

The function EcuM_EnableWakeupSources is a synchronous callout of the ECU Manager with the service ID 0x3F, which is declared via the header EcuM_Externals.h [SWS_EcuM_02918]. It serves to inform the system developer that the state SLEEP is imminent so that the wakeup sources specified in the bit field wakeupSource (type EcuM_WakeupSourceType) can be appropriately prepared and configured [SWS_EcuM_02918].

Usage and Interaction

The ECU Manager executes EcuM_EnableWakeupSources to configure the wakeup sources for the next sleep mode; this is done for each wakeup source configured in EcuMWakeupSourceMask for the targeted sleep mode [SWS_EcuM_02389]. The function has no return value (void) and expects the bit field wakeupSource as an input parameter [SWS_EcuM_02918].

Concurrency and Limitations

• Reentrancy: The function is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02918].
• Synchronism: Processing is synchronous [SWS_EcuM_02918].
• Error handling: No specific DET or DEM error messages are defined in the specification scope of the interface [SWS_EcuM_02918].

The function EcuM_GenerateRamHash serves to generate a RAM check value in the context of the ECU State Manager, with the specification referring to EcuM_CheckRamHash regarding its operation [SWS_EcuM_02919]. The generated check value presumably serves for the subsequent integrity check of the RAM in connection with sleep or low-power states. Question Q-7f316b389e1609c0 (open)

Usage and Interface

The service has the service ID 0x40 and the signature void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. The function has neither input, output, nor input/output parameters and returns no return value. Execution is synchronous.

Concurrency and Limitations

The function is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02919]. Consequently, it must not be called interrupting or concurrently from multiple contexts. The declaration is provided via the header file EcuM_Externals.h [SWS_EcuM_02919]. Interpretation: Due to the definition in EcuM_Externals.h, it is likely a user-specifically implemented callout that is called by the ECU State Manager at an appropriate point in the state sequence. Question Q-2f53f1a19cee079c (open)

Error handling

No specific error codes as well as neither DET nor DEM messages are defined for EcuM_GenerateRamHash in [SWS_EcuM_02919].

Usage and Call Context

The function EcuM_SleepActivity represents a callout of the ECU State Manager, provided in the header file EcuM_Externals.h with the service ID 0x41 [SWS_EcuM_02928]. The call takes place periodically in all reduced clock sleep modes (reduced clock sleep modes) [SWS_EcuM_02928]. The function has the signature void EcuM_SleepActivity(void), operates synchronously, and accepts neither input, output, nor input/output parameters [SWS_EcuM_02928].

Functional Tasks and Interaction

The purpose of this callout is to carry out activities during sleep: It is explicitly intended and permitted to cyclically query (poll) wakeup sources within EcuM_SleepActivity [SWS_EcuM_02928]. Furthermore, wakeup notification functions may be called directly from the callout to indicate the termination of the sleep state to the ECU State Manager [SWS_EcuM_02928].

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02928]. Since the callout returns no return value and no error parameters are defined, no direct error handling via error codes or error reporters such as DET or DEM takes place via the function interface [SWS_EcuM_02928].

Usage and Call Context

According to [SWS_EcuM_04096], the synchronous interface EcuM_StartCheckWakeup is called by the ECU firmware to start the timer CheckWakeupTimer for a specific wakeup source. For this purpose, the parameter WakeupSource of type EcuM_WakeupSourceType is passed to the function. It has no return value (void) and is provided via the header file EcuM_Externals.h.

Sequence and conditions

The execution of the function depends on the configuration of the wakeup source [SWS_EcuM_04096]:

• If EcuMCheckWakeupTimeout > 0 is configured for the respective wakeup source, the associated CheckWakeupTimer is started.
• If EcuMCheckWakeupTimeout <= 0 holds, the function call is completely ignored by the EcuM.

Concurrency and Error Handling

The function is specified as non-reentrant (Non Reentrant) [SWS_EcuM_04096]. Consequently, the caller must ensure that calls for the same or other wakeup sources do not take place concurrently. Specific error codes and notifications to DET or DEM are not specified for this call; according to the specification, a call with a non-positive timeout remains without effect, which can presumably be interpreted as tolerant interception of irrelevant timer checks [SWS_EcuM_04096]. Question Q-19d98b03d3ee7504 (open)

The callout EcuM_CheckWakeup serves to check and poll wakeup sources as well as to configure the PLL after a wakeup event [SWS_EcuM_02929]. The function is provided via the header file EcuM_Externals.h and has the service ID 0x42 [SWS_EcuM_02929].

Call Context and Semantics

• Signature and parameters: The function is executed synchronously (Synchronous), has no return value, and expects wakeupSource of type EcuM_WakeupSourceType as an input parameter [SWS_EcuM_02929].
• Callers: The callout is called by EcuM to cyclically poll a wakeup source. In addition, it must be called mandatorily by the interrupt service routine (ISR) of a wakeup source to set up the PLL and check further wakeup sources that are tied to the same interrupt [SWS_EcuM_02929].
• Polling loop: In the polling sequence, the EcuM repeatedly calls the callouts EcuM_SleepActivity and EcuM_CheckWakeup in a blocking loop until a wakeup event is reported as pending or validated [SWS_EcuM_03020].

Restrictions and Error Handling

The function is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02929]. Since calls occur both from the blocking sequence of the polling loop and from ISR contexts, the integration will likely need to ensure that no uncoordinated concurrent calls take place. Question Q-8bc8f164670a0911 (open) Specific error codes or error notifications to DET or DEM are not defined for this callout.

The synchronous function EcuM_EndCheckWakeup is called by software modules when the asynchronous check of a wakeup source (such as with an asynchronous CAN transceiver driver) yields a negative result, meaning no wakeup event was caused by this source [SWS_EcuM_02927].

Usage and Parameters

Via the input parameter WakeupSource of type EcuM_WakeupSourceType, the wakeup source is passed for which the associated monitoring timer is to be canceled [SWS_EcuM_02927]. The function returns no return value (void) and has no input/output or output parameters [SWS_EcuM_02927].

Functional principle and concurrency

• The function cancels the timer CheckWakeupTimer for the specified wakeup source; upon cancellation of this timer, the check of the wakeup source is considered completed [SWS_EcuM_02927].
• The interface is defined as synchronous and non-reentrant (Non Reentrant) [SWS_EcuM_02927].
• The declaration is provided via the header file EcuM_Externals.h [SWS_EcuM_02927].

The function EcuM_CheckRamHash is a synchronous, non-reentrant callout (declared in EcuM_Externals.h) that provides an integrity test of the RAM memory [SWS_EcuM_02921]. The function has no parameters and returns a status value of type uint8: The value 0 signals a test failure, while any other value indicates a successful pass [SWS_EcuM_02921].

According to [SWS_EcuM_02863], the module EcuM first calls [SWS_EcuM_02919] before halting the microcontroller and executes EcuM_CheckRamHash after returning from the halt state. The objective is to verify that the RAM content has remained consistent even after a long SLEEP phase [SWS_EcuM_02921].

The following boundary conditions apply to the implementation and the process:

• Algorithm and check range: The check function is provided by the system designer; it does not need to be exhaustive, but should execute quickly and detect errors with sufficient certainty [SWS_EcuM_02921]. Areas to be checked must be selected carefully; stack contents of the executing task can generally not be checked [SWS_EcuM_02921].
• Task structure: As a best practice, hash generation and checking should be executed in the same, non-preemptible task with minimal intermediate activity [SWS_EcuM_02921].
• Multi-Core: In the case of multiple processor cores with satellite EcuMs, the callout is called exclusively by the master EcuM and checks only data within its scope [SWS_EcuM_02863], [SWS_EcuM_02921].

Specific DET or DEM messages are not defined for this callout; the error response for return value 0 is presumably at the discretion of the higher-level system design [SWS_EcuM_02921]. Question Q-473ef8617db29fe3 (open)

The synchronous interface EcuM_DisableWakeupSources with the service ID 0x44 serves to configure the wakeup sources defined in the bit field parameter wakeupSource of type EcuM_WakeupSourceType such that they can no longer wake up the ECU [SWS_EcuM_02922]. The function signature is void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

According to the specification, the following properties apply to the call context and integration:

• Caller and header: The function is called by the ECU Manager module and provided via the header file EcuM_Externals.h [SWS_EcuM_02922].
• Parameters and return values: The bit field wakeupSource is passed as the only input parameter. The function has neither input/output nor output parameters and returns no return value (void) [SWS_EcuM_02922].
• Execution semantics and concurrency: Processing is synchronous. In addition, the function is specified as non-reentrant (Non Reentrant), so that concurrent or nested calls must be avoided [SWS_EcuM_02922].

Regarding error handling, the specification contains neither specific error codes nor notifications to the DET or DEM for this function call [SWS_EcuM_02922].

The callout EcuM_AL_DriverRestart is declared via the header file EcuM_Externals.h and has the service ID 0x45 [SWS_EcuM_02923]. The function has the signature void EcuM_AL_DriverRestart (void), requires no transfer parameters, and returns no return value [SWS_EcuM_02923]. The purpose of this interface is to provide driver initialization as well as further hardware-related activities during the startup phase in the wakeup case [SWS_EcuM_02923].

Mandatory requirements apply to the integration and interaction with the module EcuM:

• For re-initialization during phase WakeupRestart, the integrator must include a restart block in the integration code for EcuM_AL_DriverRestart, which uses the configured list EcuMDriverRestartList [SWS_EcuM_02947] [SWS_EcuM_02923].
• The list EcuMDriverRestartList can contain drivers that function as wakeup sources [SWS_EcuM_02562]. In this case, EcuM_AL_DriverRestart must re-arm the trigger mechanism of the callback for wakeup detection (“wakeup detected”) of these drivers [SWS_EcuM_02562].

Regarding runtime behavior, the function is defined as synchronous and non-reentrant [SWS_EcuM_02923]. Since this is application-specific integration code, the specification defines no dedicated error codes as well as no standardized messages to DET or DEM at this interface.

The callout function EcuM_StartWakeupSources serves to start and put the passed wakeup source(s) into operation such that they are prepared for the subsequent execution of the wakeup validation [SWS_EcuM_02924].

Usage and Call Context

The function is specified as a synchronous call with the service ID 0x46, has no return value (void), and is provided via the header file EcuM_Externals.h [SWS_EcuM_02924].

• Parameter wakeupSource (in): Passes the wakeup source to be started or a bitmask of multiple wakeup sources of type EcuM_WakeupSourceType to the callout function [SWS_EcuM_02924]. Additional input or output parameters (inout/out) do not exist [SWS_EcuM_02924].

Concurrency and Limitations

With regard to the execution environment, EcuM_StartWakeupSources is classified as non-reentrant (Non Reentrant) [SWS_EcuM_02924]. Callers must therefore ensure that the function is not executed concurrently from interrupting interrupt service routines or parallel tasks.

Interaction and Error Handling

Since EcuM_StartWakeupSources is declared as a callout, the hardware-related activation of the affected sources is the responsibility of the application-specific implementation by the system integrator [SWS_EcuM_02924]. The specification provides neither error messages to DET or DEM nor specific error return values for this interface [SWS_EcuM_02924]; any error states when starting the sources are therefore presumably handled in an integration-specific manner within the callout. Question Q-b595e7175c34a831 (open)

The function EcuM_CheckValidation serves as a callout interface of the ECU State Manager for validating a wake-up source [SWS_EcuM_02925]. The EcuM calls this function to determine whether a detected wake-up event is valid [SWS_EcuM_02925].

use

The callout has the service ID 0x47 and is provided via the header file EcuM_Externals.h [SWS_EcuM_02925]. wakeupSource of type EcuM_WakeupSourceType serves as the passed parameter, by which the wake-up source to be validated is identified [SWS_EcuM_02925]. The function returns no value (void) and has no output or input/output parameters [SWS_EcuM_02925]. Execution is synchronous [SWS_EcuM_02925].

Error handling

Specific error codes, return values in case of error, or reports to DET or DEM are not defined for this callout in the specification.

Concurrency and Limitations

Regarding concurrency, EcuM_CheckValidation is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02925]. The calling context of the EcuM must ensure that no parallel or nested calls occur for the same or different wake-up sources.

Interaction

If a valid wake-up event was detected during execution, it must mandatorily be reported back to the EcuM via the function call EcuM_ValidateWakeupEvent() [SWS_EcuM_02925]. Interpretation: The device-specific logic for checking the hardware and deciding on validity is likely implemented entirely in integration code. Question Q-08061e09b474728d (open)

The callout function EcuM_StopWakeupSources of the module EcuM (Classic Platform) serves to deliberately stop the passed wakeup source(s) after an unsuccessful wakeup validation [SWS_EcuM_02926]. The declaration of this synchronous interface is available via the header file EcuM_Externals.h and carries the service ID 0x48 [SWS_EcuM_02926].

Usage and interface parameters:

• Input parameter: As the only parameter, wakeupSource of type EcuM_WakeupSourceType is passed, which specifies the wakeup source(s) to be stopped [SWS_EcuM_02926].
• Return value and inputs/outputs: There exist neither input/output parameters (inout) nor output parameters (out) [SWS_EcuM_02926]. The function returns no return value (void) to the caller [SWS_EcuM_02926].
• Execution behavior: Function execution is specified as synchronous (Synchronous) [SWS_EcuM_02926].

Concurrency and error handling:

The interface is specified as non-reentrant (Non Reentrant) [SWS_EcuM_02926]. Parallel calls are therefore not permitted and must be avoided by the caller. The specification defines neither specific error codes nor return values or notifications to the Default Error Tracer (DET) or the Diagnostic Event Manager (DEM) module for this callout [SWS_EcuM_02926]. Interpretation: Since the function is provided as an external callout via EcuM_Externals.h, the hardware-related deactivation of the relevant wakeup hardware as well as the internal error handling is the responsibility of the user-specific implementation. Question Q-b537c805bed751ab (open)

Usage and Call Context

The function EcuM_MainFunction has the signature void EcuM_MainFunction(void) with the service ID 0x18 and is provided via the header file SchM_EcuM.h [SWS_EcuM_02837]. It takes no parameters and returns no return value [SWS_EcuM_02837]. Its task is to process all activities of the ECU State Manager while the operating system is running ("OS is up and running") [SWS_EcuM_02837]. In doing so, the function is typically expected to be called periodically by the scheduler (interpretation: integration via SchM_EcuM.h). Question Q-ca471f22bdb1f11d (open)

Interaction and tasks

During ongoing operation, EcuM_MainFunction assumes central coordination tasks:

• Validation of wakeup sources: If a list of wakeup source candidates is present after completion of the WakeupRestart sequence, the EcuM module validates these candidates within EcuM_MainFunction [SWS_EcuM_02539].
• Expiration of the validation timeout: If the validation timeout for a pending wakeup event expires, the function OR-combines the associated bit into the internal variable for expired wakeup events [SWS_EcuM_04081]. In addition, it notifies the BSW management via BswM_EcuM_Current_Wakeup with a EcuM_WakeupSourceType bitmask of the event and the status ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Alarm Clock Service: If the service is present via EcuMAlarmClockPresent, EcuM_MainFunction updates the alarm clock timer [SWS_EcuM_04002].

Constraints and Instances

As an essential constraint for multi-core or multi-instance architectures, EcuM_MainFunction must be executed in all instances of the EcuM [SWS_EcuM_04011].

The data type EcuM_RunStatusType is defined as uint8 and is provided via the header EcuM.h ([SWS_EcuM_04120]). It serves for the formal representation of the current status of the run request protocol in the ECU Manager and is transmitted as a result to the Basic Software Mode Manager (BswM) ([SWS_EcuM_04120]).

The permissible value range comprises three discrete states ([SWS_EcuM_04120]):

• ECUM_RUNSTATUS_UNKNOWN (value 0): Represents an unknown status and simultaneously serves as the defined initialization value (Init Value).
• ECUM_RUNSTATUS_REQUESTED (value 1): Identifies the state that the RUN status was actively requested by the ECU Manager.
• ECUM_RUNSTATUS_RELEASED (value 2): Signals that the RUN status was released again by the ECU Manager.

Regarding interaction, requirement [SWS_EcuM_04121] obligates the ECU Manager module to bindingly inform the BswM about the current state of the run request protocol based on the status values listed in EcuM_RunStatusType. Interpretation: Since the requirement does not specify a particular function signature or calling convention for the message flow, the status information is typically expected to be passed to the BswM module via an internal notification function or callback interface. Question Q-e136b90c2edbc29c (open) Specific error codes, DET or DEM reports, as well as special reentrancy conditions are not provided for this elementary data type in the present requirements.

According to [SWS_EcuM_04041], the data type EcuM_WakeupStatusType describes the possible states of a wakeup source in the ECU State Manager. The type is derived from the base type uint8 and is provided via the header EcuM.h [SWS_EcuM_04041].

The range of values represents the lifecycle of a wakeup event across four states [SWS_EcuM_04041]:

• ECUM_WKSTATUS_NONE (value 0): No pending wakeup event was detected [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (value 1): A wakeup event was detected, but is not yet validated [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (value 2): The wakeup event is valid and has been successfully confirmed [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (value 3): The wakeup event was not validated in time and has consequently expired [SWS_EcuM_04041].

Usage and interaction: The type serves as a central status representation for wakeup sources. Interpretation: Callers are likely to evaluate this status within status queries to determine whether a wakeup source is actively being validated, has already signaled a valid wakeup, or the validation time window has been exceeded. Question Q-a3f721e8f1753eb1 (open)

The type EcuM_StateType is a data type derived from uint8, which is provided via the header EcuM.h and represents the operating states of the ECU State Manager [SWS_EcuM_91005]. The EcuM module is required to define all states listed in EcuM_StateType [SWS_EcuM_02664]. The range of values comprises the substate mask ECUM_SUBSTATE_MASK (0x0f) as well as the main states ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40), and ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Usage and Interaction

The data type functions as a central parameter for state communication between the BswM and the EcuM:

• State change to EcuM: Via the synchronous and reentrant function call EcuM_SetState(EcuM_StateType state) with the service ID 0x2b, the BswM notifies the EcuM module of a state change [SWS_EcuM_04122].
• State reporting to BswM: The EcuM reports the current state to the BswM by calling the interface BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Concurrency, ordering, and error handling

With regard to temporal ordering, the requirement applies that a new state may only be set by the EcuM once the RTE has provided its feedback via the corresponding acknowledgement port [SWS_EcuM_04143]. Specific error codes, return values, or DET/DEM messages are not provided for this data type in the present sources.

The type EcuM_Mode is defined as ModeDeclarationGroup according to [SWS_EcuM_04107] and represents the central states of the ECU State Manager. STARTUP is defined as the initial mode. In addition, the group includes the defined modes POST_RUN, RUN, SHUTDOWN, and SLEEP [SWS_EcuM_04107].

In the system composite, EcuM_Mode serves as the type base for the mode group currentMode within the service interface EcuM_CurrentMode [SWS_EcuM_04108]. Via this interface, the current ECU mode can be queried or signaled to other software components via the RTE mode mechanism.

With regard to call context and concurrency, the specification of the type itself contains no explicit restrictions regarding reentrancy or error codes; management of state transitions takes place via the associated service interfaces of the EcuM.

The element currentMode is defined as a provided port of the module EcuM and provides the service interface EcuM_CurrentMode for the software architecture [SWS_EcuM_04112]. This service interface is used to read out the current ECU mode and encapsulates the mode group currentMode based on the data type EcuM_Mode [SWS_EcuM_04108].

During ongoing system operation, it is used to signal state changes:

• Invocation and usage: As soon as a mode switch occurs, the EcuM reports it via RTE mode ports to software components (SW-Cs) [SWS_EcuM_04133]. Under the specification assumption of the port name currentMode and when using the direct RTE API, the function Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) is called for this purpose [SWS_EcuM_04133].
• Parameters and return value: Parameter mode passes the mode to be newly entered to the RTE [SWS_EcuM_04133]. The return value of type Rte_StatusType provided by the switch API is not evaluated, but according to the specification must imperatively be ignored [SWS_EcuM_04133].
• Interaction: A software component that is to be informed about mode changes must request the mode switch interface EcuM_CurrentMode as a required port [SWS_EcuM_04133].

Usage and Value Range

The data type EcuM_ShutdownModeType is based on uint16 and is provided via the header file Rte_EcuM_Type.h [SWS_EcuM_04101]. It maps the modes configured in the ECU State Manager. Its value range includes:

• the configured sleep modes according to EcuMSleepModeId [SWS_EcuM_04101] as well as
• the configured reset modes, calculated from the offset 256 + EcuMResetModeId [SWS_EcuM_04101].

Interaction and Call Context

The type is used in synchronous and reentrant services of the ECU Manager:

• EcuM_SelectShutdownTarget takes shutdownMode as an input parameter to define the concrete sleep mode (for target ECUM_SHUTDOWN_TARGET_SLEEP) or reset mechanism (for target ECUM_SHUTDOWN_TARGET_RESET) [SWS_EcuM_02822].
• EcuM_GetShutdownTarget returns via a pointer parameter to EcuM_ShutdownModeType which configured sleep or reset mode is selected for the current shutdown target [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget outputs the shutdown mode of the preceding shutdown process via an output parameter [SWS_EcuM_02825]. Via the service interface EcuM_ShutdownTarget, this functionality is also available to software components (SW-Cs) [SWS_EcuM_03011].

Error Handling and Boundary Conditions

The functions return Std_ReturnType. If, for example, a NULL pointer is passed to EcuM_GetShutdownTarget or EcuM_GetLastShutdownTarget, the call fails with E_NOT_OK [SWS_EcuM_02824], [SWS_EcuM_02825]. Upon successful execution, the services report E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].