AUTOSAR EcuM规范解析（二）

​
规范前序内容请调整至：AUTOSAR EcuM规范解析（一）

持续更新中…

7.8 多核心ECU的考虑因素

ECU管理器模块提供了一项可选的持久时钟服务，该服务即使在睡眠期间也能保持“活跃”状态。因此，它可以保证ECU在未来的特定时间被唤醒（假设硬件没有故障），并为长期活动（即按小时、天甚至年计算的活动）提供时钟服务。

通常，这项服务通过ECU中能够触发唤醒的计时器来实现。不过，在某些情况下，外部设备也可以使用常规中断线来定期唤醒ECU。无论使用哪种机制，该服务都会私下占用一个唤醒源。

ECU管理器模块维护一个主闹钟时钟，其值决定了ECU将被唤醒的时间。此外，ECU管理器还管理一个内部时钟，即EcuM时钟，用于与主闹钟进行比较。

需要注意的是，闹钟唤醒机制仅与睡眠阶段相关。然而，软件组件（SW-Cs）和基础软件（BSW）模块可以在运行阶段（且仅在运行阶段）设置和获取闹钟值，这些值在睡眠阶段会被遵守。

与其他可利用ECU管理器模块通用功能实现的定时/唤醒机制相比，闹钟时钟服务在计时器到期前不会启动唤醒重启序列。当ECU模块检测到其计时器已引发唤醒事件时，它会递增计时器，除非时钟时间已超过闹钟时间，否则会立即返回睡眠状态。

[SWS_EcuM_04069]⌈当闹钟时钟服务存在时（参见EcuMAlarmClockPresent ECUC_EcuM_00199），ECU管理器模块应维护一个EcuM时钟，其时间应为从电池连接开始计算的秒数。⌋()

[SWS_EcuM_04086]⌈EcuM时钟应在运行阶段和睡眠阶段跟踪时间。⌋()

[SWS_EcuM_04087]⌈在硬件允许的情况下，EcuM时钟时间不应因ECU复位而被重置。⌋()

[SWS_EcuM_04088]⌈应恰好有一个唤醒源分配给EcuM时钟（参见EcuMAlarmWakeupSource ECUC_EcuM_00200）。⌋()

7.8.1 核心角色分配

软件组件（SW-Cs）和基础软件（BSW）模块各自可以维护一个闹钟（用户闹钟）。每个用户闹钟（参见EcuMAlarmClock ECUC_EcuM_00184）都与一个EcuM用户（参见ECUC_EcuM_00195）相关联，该用户用于标识相应的软件组件或基础软件模块。

[SWS_EcuM_04070]⌈每个EcuM用户最多可拥有一个用户闹钟。⌋()

[SWS_EcuM_04071]⌈一个EcuM用户不得设置另一个用户的闹钟值。⌋()

[SWS_EcuM_04072]⌈ECU管理器模块应始终将主闹钟值设置为最早的用户闹钟值。⌋()

这也意味着，当某个EcuM用户中止其闹钟，且该用户闹钟决定了当前的主闹钟值时，ECU管理器模块应将主闹钟值设置为下一个最早的用户闹钟值。

[SWS_EcuM_04073]⌈仅授权的EcuM用户可以设置EcuM时钟时间（参见ECUC_EcuM_00197，即ECUC_EcuM_00168中的用户列表）。⌋()

SWS_EcuM_04073的理由：通常，EcuM用户不应能够设置EcuM时钟时间。但EcuM时钟时间可被设置为任意时间，以便测试那些需要数天才能到期的闹钟。

7.8.2 EcuM时钟时间

[SWS_EcuM_04089]⌈如果底层硬件机制是基于时钟滴答的，ECU管理器（ECUM）应相应地“校正”时间。⌋()

7.8.2.1 运行阶段的EcuM时钟时间

在运行阶段，EcuM_MainFunction会递增EcuM时钟。它使用标准的操作系统机制（闹钟/计数器）来获取时间。请注意，计数器与EcuM时间（以秒为单位，参见SWS_EcuM_04069）在粒度上存在差异。

7.8.2.2 睡眠阶段的EcuM时钟时间

根据所选的睡眠模式（由EcuMSleepModeSuspend参数决定），睡眠期间递增EcuM时钟有两种方式：

在暂停序列（参见7.5.2节“暂停序列中的活动”）中，通用定时器（GPT）驱动必须置于GPT_MODE_SLEEP模式，仅配置时基所需的那些定时器通道。这还要求GPT通过Gpt_EnableWakeup API启用基于定时器的唤醒通道。理想情况下，Gpt_StartTimer API会设置为1秒，但如果无法达到该值，EcuM需要更频繁地被唤醒，通过累积多次定时器唤醒，直到累计满1秒后再递增时钟值。

在轮询序列（参见7.5.3节“轮询序列中的活动”）中，假设时间概念仍然可用，EcuM时钟可在EcuM_SleepActivity函数中通过EcuM_SetClock函数定期更新。仅当累计满1秒时，时钟才会递增。

在睡眠期间时钟递增后，两种情况下ECU管理器模块都必须评估主闹钟是否已到期。如果已到期，BSW模式管理器（BswM）将启动完整的启动流程，或让ECU再次进入睡眠状态。

[SWS_EcuM_04009]⌈退出睡眠状态时，ECU管理器模块将中止所有活跃的用户闹钟和主闹钟。这意味着无论是时钟引发的唤醒，还是其他事件导致的唤醒，都会清除所有闹钟。⌋(SRS_ModeMgm_09187)

[SWS_EcuM_04010]⌈在StartPreOS序列、唤醒重启序列和OffPreOS序列中，用户闹钟和主闹钟都应被取消。⌋(SRS_ModeMgm_09188)

7.9 多核（MultiCore）

BSW 模块可分布在不同的分区中。一个分区可视为一个独立的部分，映射到一个核上。因此，每个核（无论在单核还是多核架构中）至少包含一个分区，也可以包含任意数量的分区，但任何分区都不能跨多个核。

BSW 模块可分布在不同的分区中，进而分布在不同的核上。有些 BSW 模块（如 BSW 模式管理器（BswM））必须包含在每个分区中；其他模块（如操作系统（OS）或 ECU 管理器（EcuM））则必须在每个核的一个分区中包含。

在多核架构中，ECU 管理器必须以每个核一个实例的方式分布。

有一个指定的主核，引导加载程序通过 EcuM_Init 启动主核上的主 ECU 管理器。主 ECU 管理器启动一些驱动程序，确定后构建配置，并启动所有剩余的核及其所有附属 ECU 管理器。
每个 ECU 管理器现在启动核本地的操作系统和所有核本地的 BSW 模式管理器（每个分区中恰好有一个 BSW 模式管理器）。

如果 ECU 管理器的相同镜像在 ECU 的每个核上执行，那么 ECU 管理器在不同核上的行为必须有所不同。ECU 管理器可通过首先检测自身处于主核还是从核来实现这一点，并相应地采取行动。

ECU 管理器模块支持多核 ECU 上与传统 ECU 相同的阶段（即启动（STARTUP）、运行（UP）、关机（SHUTDOWN）和睡眠（SLEEP））。

如果使用安全机制，ECU 状态管理器必须以完全信任级别运行。

本节使用了 ECU 管理器先前版本中关于各种 ECU 状态的术语，特别是运行（Run）/ 运行后（PostRun）。通过灵活的 ECU 管理，系统集成商确定 ECU 状态的名称和语义。然而，必须采用确保去初始化阶段的方法。因此，此处使用的名称不具有规范性。

7.9.1 主核（Master Core）

有一个明确的主核。主核是哪个核由引导加载程序确定。主核的 ECU 管理器作为第一个 BSW 模块启动，并执行初始化操作。
然后，它启动所有其他核以及所有其他 ECU 管理器。
当这些启动后，它会与每个附属 ECU 管理器一起初始化核本地的操作系统和 BSW 模式管理器。

7.9.2 从核（Slave Core）

每个从核上必须运行一个附属 ECU 管理器。如果一个核包含多个分区，则每个核只需存在一个 ECU 管理器。
7.9.3 主核与从核的通信（Master Core – Slave Core Signalling）
本节讨论 BSW 可通过其在核间通信的一般机制。它假设对调度器管理器（SchM）有基本了解，调度器管理器在运行时环境（RTE）中有描述和规定。

7.9.3.1 BSW 层

操作系统提供了用于同步主核和从核上操作系统启动的基本机制。调度器管理器提供了跨分区边界通信 BSW 模块的基本机制。每个核上有一个 BSW 模式管理器，负责启动和停止运行时环境。
有关解决方案的更多完整描述以及选择方案时的考虑因素，请参考《模式管理指南》[23]。

7.9.3.2 关机同步示例

在调用 ShutdownAllCores 之前，“主” ECU 管理器模块必须启动所有 “从” ECU 管理器模块的关机，并等待所有模块完成其负责的 BSW 模块的去初始化并成功关机。

因此，主 ECU 管理器模块设置一个所有从模块都能读取的关机标志。之后，ECU 管理器为每个配置的从核激活任务。从模块在主程序中读取该标志，并在收到请求时关机。任务名称为 “EcuM_SlaveCore_Task”，其中 X 是一个数字。该任务需要由集成商配置。需要激活的任务数量可通过计算 EcuMPartitionRef 的实例数减一来确定，因为一个 EcuMFlexPartionRef 用于主核。
示例：配置了三个 EcuMPartitionRef 实例。然后，在调用 EcuM_GoDownHaltPoll () 期间，将启动 “EcuM_SlaveCore1_Task” 和 “EcuM_SlaveCore2_Task”。从模块在主程序中读取该标志，并在收到请求时关机。

操作系统跨核扩展了 OSEK 的 SetEvent 函数。一个核上的任务可以等待另一个核上设置的事件。图 18 说明了这如何应用于在调用 ShutdownAllCores 之前同步核的问题（其中省略了去初始化细节）。Set/WaitEvent 函数接受一个位掩码，可用于指示各个从核上的关机就绪状态。每个来自 “从” ECU 管理器模块的 SetEvent 调用都会停止 “主” ECU 管理器模块的等待。因此，“主” ECU 管理器模块必须跟踪各个从核的状态，并等待直到所有核都已注册其就绪状态。

如果调用者已经获取了资源或自旋锁，则 WaitEvent () 函数可替换为 GetEvent () 循环。

7.9.4 运行阶段（UP Phase）

从硬件角度来看，所有核上都可能发生唤醒中断。然后，整个 ECU 被唤醒，运行在该核上的 ECU 管理器处理唤醒事件。

[SWS_EcuM_04011]⌈ECU 管理器主函数（EcuM_MainFunction）应在所有 ECU 管理器实例中运行。⌋()

[SWS_EcuM_04012]⌈每个 ECU 管理器模块实例应处理其所在核的唤醒事件。⌋()

与单核情况一样，BSW 模式管理器（由集成商配置）负责控制 ECU 资源，确定本地核是否可以断电或暂停，以及在将控制权交给其核的 ECU 管理器之前去初始化相应的应用程序和 BSW。

7.9.5 启动阶段（STARTUP Phase）

ECU 管理器模块在所有核上的功能几乎相同。也就是说，与单核情况一样，ECU 管理器模块执行启动规定的步骤；最重要的是启动操作系统，初始化调度器管理器，并启动核本地的 BSW 模式管理器。

主 ECU 管理器在调用初始化块 1（InitBlock 1）并完成复位 / 唤醒管理后激活所有从核。从核被激活后，执行其启动程序，在其核上调用 EcuM_Init。

每个 ECU 管理器在其核上调用 StartOS 后，操作系统在执行核特定的启动钩子之前同步各个核，并在每个核上执行第一个任务之前再次同步各个核。

每个核上都执行 StartPostOS，每个核上都初始化调度器管理器。每个 ECU 管理器初始化所有核本地的 BSW 模式管理器。

每个分区上的一个 BSW 模式管理器必须启动该核的运行时环境。
[SWS_EcuM_04093]⌈ECU 管理器模块应在每个核上启动调度器管理器（SchM）和操作系统（OS）。⌋()

[SWS_EcuM_04014]⌈ECU 管理器模块应在主核和所有从核上为所有核本地的 BSW 模式管理器调用 BswM_Init。⌋()

7.9.5.1 主核启动（Master Core STARTUP）

[SWS_EcuM_04015]⌈

[SWS_EcuM_04016]⌈

7.9.5.2 从核启动（Slave Core STARTUP）
[SWS_EcuM_04017]⌈

[SWS_EcuM_04018]⌈

7.9.6 关机阶段（SHUTDOWN Phase）

当前不支持单个核的关机（即 ECU 的其余部分继续运行）。所有核同时关机。

当 ECU 需要关机时，主 ECU 管理器模块调用 ShutdownAllCores，而不是以某种方式在各个核上调用 ShutdownOS。ShutdownAllCores 停止所有核上的操作系统，并停止所有核。

由于主核可能在所有从核完成处理之前发出 ShutdownAllCores，因此在进入关机阶段之前必须同步各个核。

BSW 模式管理器（分布在所有分区中）确定 ECU 应关机，并与 ECU 中的每个 BSW 模式管理器同步。所有 BSW 模式管理器促使分区的所有 BSW、软件组件（SW-Cs）和复杂设备驱动程序（CDDs）去初始化，并向其他 BSW 模式管理器发送适当的信号以指示其准备好关机。

为了关闭 ECU，位于主 ECU 管理器同一分区中的 BSW 模式管理器最终在主核上调用 GoOff，主核将该请求分发到所有从核。“主” ECU 管理器去初始化 BSW 模式管理器和调度器管理器。从核上的 ECU 管理器去初始化其调度器管理器和 BSW 模式管理器，然后发送信号指示该核已准备好执行 ShutdownOS（再次参见 7.9.3 节 “主核与从核的通信” 了解详情）。

主 ECU 管理器等待每个从核 ECU 管理器发出的信号，然后像在主核上通常那样启动关机（主 ECU 管理器调用 ShutdownAllCores，ECU 通过全局关机钩子进入关机状态）。

7.9.6.1 主核关机（Master Core SHUTDOWN）

[SWS_EcuM_04019]⌈

[SWS_EcuM_04020]⌈

7.9.6.2 从核关机（Slave Core SHUTDOWN）

[SWS_EcuM_04021]⌈

[SWS_EcuM_04022]⌈

7.9.7 睡眠阶段（SLEEP Phase）

当请求的关机目标为睡眠（Sleep）时，所有核同时进入睡眠状态。MCU 必须为每个核发出暂停（halt）指令。由于任务定时和优先级是操作系统中核本地的，因此暂停后调度器和运行时环境都不需要同步。由于主核可能在所有从核完成处理之前发出 MCU 暂停指令，因此在进入 GoHalt 之前必须同步各个核。

BSW 模式管理器确定应启动睡眠，并向每个核分发适当的 ECU 模式。从核上的 BSW、软件组件和复杂设备驱动程序必须由其分区本地的 BSW 模式管理器通知，进行适当的去初始化，并向 BSW 模式管理器发送适当的模式请求以指示其就绪状态。

如果 ECU 进入睡眠状态，“暂停” 必须同步，以便在主核计算校验和之前所有从核都已暂停。主核上的 ECU 管理器使用与 GoOff 时同步核相同的 “信号” 机制。

同样，主核上的 ECU 管理器必须在将从核从 “暂停” 状态释放之前验证校验和。

7.9.7.1 主核睡眠（Master Core SLEEP）

[SWS_EcuM_04023]⌈

[SWS_EcuM_04024]⌈

⌋(SRS_ModeMgm_09239)

[SWS_EcuM_04025]⌈

[SWS_EcuM_04026]⌈

7.9.7.2 从核睡眠（Slave Core SLEEP）

[SWS_EcuM_04027]⌈

[SWS_EcuM_04028]⌈

[SWS_EcuM_04029]⌈

[SWS_EcuM_04030]⌈

7.9.8 可运行实体和入口点（Runnables and Entry points）

7.9.8.1 内部行为（Internal behavior）

[SWS_EcuM_03018]⌈ECU 管理器模块的内部行为定义如下。此详细描述仅用于配置本地运行时环境。

InternalBehavior EcuStateManager {
// Runnable entities of the EcuStateManager
RunnableEntity SelectShutdownTarget
symbol “EcuM_SelectShutdownTarget”
canbeInvokedConcurrently = TRUE
RunnableEntity GetShutdownTarget
symbol “EcuM_GetShutdownTarget”
canbeInvokedConcurrently = TRUE
RunnableEntity GetLastShutdownTarget
symbol “EcuM_GetLastShutdownTarget”
canbeInvokedConcurrently = TRUE
RunnableEntity SelectShutdownCause
symbol “EcuM_SelectShutdownCause”
canbeInvokedConcurrently = TRUE
RunnableEntity GetShutdownCause
symbol “EcuM_GetShutdownCause”
canbeInvokedConcurrently = TRUE
RunnableEntity SelectBootTarget
symbol “EcuM_SelectBootTarget”
canbeInvokedConcurrently = TRUE
RunnableEntity GetBootTarget
symbol “EcuM_GetBootTarget”
canbeInvokedConcurrently = TRUE
RunnableEntity SetRelWakeupAlarm
symbol “EcuM_SetRelWakeupAlarm”
canbeInvokedConcurrently = TRUE
RunnableEntity SetAbsWakeupAlarm
symbol “EcuM_SetAbsWakeupAlarm”
canbeInvokedConcurrently = TRUE
RunnableEntity AbortWakeupAlarm
symbol “EcuM_AbortWakeupAlarm”
canbeInvokedConcurrently = TRUE
RunnableEntity GetCurrentTime
symbol “EcuM_GetCurrentTime”
canbeInvokedConcurrently = TRUE
RunnableEntity GetWakeupTime
symbol “EcuM_GetWakeupTime”
canbeInvokedConcurrently = TRUE
RunnableEntity SetClock
symbol “EcuM_SetClock”
canbeInvokedConcurrently = TRUE
RunnableEntity RequestRUN
symbol “EcuM_RequestRUN”
canbeInvokedConcurrently = TRUE
RunnableEntity ReleaseRUN
symbol “EcuM_ReleaseRUN”
canbeInvokedConcurrently = TRUE
RunnableEntity RequestPOSTRUN
symbol “EcuM_RequestPOST_RUN”
canbeInvokedConcurrently = TRUE
RunnableEntity ReleasePOSTRUN
symbol “EcuM_ReleasePOST_RUN”
canbeInvokedConcurrently = TRUE
// Port present for each user. There are NU users
SR000.RequestRUN -> RequestRUN
SR000.ReleaseRUN -> ReleaseRUN
SR000.RequestPOSTRUN -> RequestPOSTRUN
SR000.ReleasePOSTRUN -> RequestPOSTRUN
PortArgument {port=SR000, value.type=EcuM_UserType,
value.value=EcuM_User[0].User}
(...)
SRnnn.RequestRUN -> RequestRUN
SRnnn.ReleaseRUN -> ReleaseRUN
SRnnn.RequestPOSTRUN -> RequestPOSTRUN
SRnnn.ReleasePOSTRUN -> RequestPOSTRUN
PortArgument {port=SRnnn, value.type=EcuM_UserType,
value.value=EcuM_User[nnn].User}
shutDownTarget.SelectShutdownTarget -> SelectShutdownTarget
shutDownTarget.GetShutdownTarget -> GetShutdownTarget
shutDownTarget.GetLastShutdownTarget -> GetLastShutdownTarget
shutDownTarget.SelectShutdownCause -> SelectShutdownCause
shutDownTarget.GetShutdownCause -> GetShutdownCause
bootTarget.SelectBootTarget -> SelectBootTarget
bootTarget.GetBootTarget -> GetBootTarget
alarmClock.SetRelWakeupAlarm-> SetRelWakeupAlarm
alarmClock.SetAbsWakeupAlarm -> SetAbsWakeupAlarm
alarmClock.AbortWakeupAlarm -> AbortWakeupAlarm
alarmClock.GetCurrentTime -> GetCurrentTime
alarmClock.GetWakeupTime -> GetWakeupTime
alarmClock.SetClock -> SetClock
};

7.10 ECU管理器模式处理（EcuM Mode Handling）

ECU状态管理器提供接口，供软件组件（SW-Cs）可选地请求和释放运行（RUN）模式与运行后（POST_RUN）模式。

ECU管理器Flex（EcuMFlex）对软件组件发出的请求和释放进行仲裁，并将结果传递给BSW模式管理器（BswM）。ECU管理器与BSW模式管理器之间的协作是必要的，因为只有BSW模式管理器能够决定何时可以切换到不同的模式。由于ECU管理器没有自己的状态机，它依赖于BSW模式管理器进行的状态转换。因此，ECU管理器不会请求状态，而是将所有请求的当前仲裁状态通知给BSW模式管理器，并在运行时环境（RTE）执行完某个特定模式的所有可运行实体后通知BSW模式管理器。

图35展示了ECU模式处理的架构组件。

图35 - ECU模式处理的架构组件

[SWS_EcuM_04115]⌈当容器EcuModeHandling（参见10.2）可用时，应应用ECU模式处理。⌋(SRS_ModeMgm_09116)

[SWS_EcuM_04116]⌈当BSW模式管理器通过EcuM_SetState()设置ECU管理器的状态时，ECU管理器应向运行时环境指示相应的模式。⌋(SRS_ModeMgm_09116)

[SWS_EcuM_04117]⌈当最后一个运行（RUN）请求被释放后，ECU状态管理器模块应使用API BswM_EcuM_RequestedState(POST_RUN, ECUM_RUNSTATUS_RELEASED)向BSW模式管理器请求运行后（POST_RUN）状态。⌋(SRS_ModeMgm_09116)

如果软件组件需要在运行后（POST_RUN）阶段执行运行后活动（例如，准备关机），则必须在释放运行（RUN）请求之前请求运行后（POST_RUN）模式。否则，无法保证该软件组件有机会运行其运行后（POST_RUN）代码。

[SWS_EcuM_04118]⌈当ECU状态管理器未处于软件组件请求的状态时，应使用BswM_EcuM_RequestedState() API将请求的状态通知给BSW模式管理器。⌋(SRS_ModeMgm_09116)

运行后（POST_RUN）状态为软件组件提供了一个运行后阶段，允许它们保存重要数据或关闭外设。

[SWS_EcuM_04119]⌈当最后一个运行后（POST_RUN）请求被释放后，ECU状态管理器模块应使用API BswM_EcuM_RequestedState(SHUTDOWN, ECUM_RUNSTATUS_RELEASED)向BSW模式管理器请求关机（SHUTDOWN）状态。⌋(SRS_ModeMgm_09116)

提示：为防止ECU模式的模式机实例滞后以及ECU管理器与运行时环境的状态不同步，ECU管理器可以使用模式切换通知的确认反馈。

请注意，ECU管理器仅请求在运行（RUN）模式与运行后（POST_RUN）模式之间进行切换，睡眠（SLEEP）模式必须由BSW模式管理器设置，因为ECU管理器不知道何时可以进入该模式。

状态	描述
启动（STARTUP）	初始值。当调用Rte_Start()时由运行时环境设置。
运行（RUN）	一旦所有必要的BSW模块初始化完成，BSW模式管理器将切换到该模式。
运行后（POST_RUN）	当没有运行（RUN）请求时，ECU管理器请求运行后（POST_RUN）模式。
睡眠（SLEEP）	当没有运行（RUN）和运行后（POST_RUN）请求且关机目标设置为睡眠（SLE

7.11 高级主题（Advanced Topics）

7.11.1 与引导加载程序的关系（Relation to Bootloader）

引导加载程序（Bootloader）并非AUTOSAR的一部分。但应用程序需要一个接口来激活引导加载程序。为此，提供了两个函数：
EcuM_SelectBootTarget（参见SWS_EcuM_02835）和EcuM_GetBootTarget（参见SWS_EcuM_02836）。

引导加载程序、系统供应商引导加载程序和应用程序是独立的程序镜像，在许多情况下甚至可以单独烧录。从一个镜像切换到另一个镜像的唯一方式是通过复位。引导菜单会根据所选的引导目标分支到一个或另一个镜像。

7.11.2 与复杂驱动程序的关系（Relation to Complex Drivers）

如果复杂驱动程序处理唤醒源，它必须遵循本文档中规定的唤醒事件处理协议。

7.11.3 启动和关机期间的错误处理（Handling Errors during Startup and Shutdown）

[SWS_EcuM_02980]⌈ECU管理器模块应忽略初始化期间发生的所有类型的错误，例如初始化函数返回的值⌋()

初始化是一个配置问题（参见EcuMDriverInitListZero（ECUC_EcuM_00114）、EcuMDriverListOne（ECUC_EcuM_00111）和EcuMDriverRestartList（ECUC_EcuM_00115）），因此无法标准化。

BSW模块自身负责直接向诊断事件管理器（DEM）模块或默认错误跟踪器（DET）模块报告在其初始化期间发生的错误，如其软件规范中所规定。ECU管理器模块不报告这些错误。BSW模块还负责采取任何特殊措施来应对在其初始化期间发生的错误。

7.12 错误（Errors）

AUTOSAR基础软件模块通常会向默认错误跟踪器（DET，用于开发阶段错误）或诊断事件管理器（DEM，用于生产阶段错误）报告错误。

ECU管理器对错误的处理方式不同，它不会向DEM/DET报告错误。

如果需要向DEM/DET报告错误，用户可以在EcuM_ErrorHook()中执行相关操作。

以下子章节包含了所有可能由ECU管理器报告的错误代码（除了集成商定义的个别错误代码）。

7.12.1 开发错误（Development Errors）

[SWS_EcuM_04032]⌈
所有错误的值可在实现过程中分配。

错误类型	相关错误代码	值（十六进制）
服务在初始化前被调用	ECUM_E_UNINIT	由实现分配
被配置禁用的函数被调用	ECUM_E_SERVICE_DISABLED	由实现分配
传递了无效指针作为参数	ECUM_E_NULL_POINTER	由实现分配
参数无效（非特定）	ECUM_E_INVALID_PAR	由实现分配
作为参数传递给服务的状态超出范围（特定参数检查）	ECUM_E_STATE_PAR_OUT_OF_RANGE	由实现分配
向API传递了未知的唤醒源	ECUM_E_UNKNOWN_WAKEUP_SOURCE	由实现分配
初始化失败	ECUM_E_INIT_FAILED	由实现分配

表7 - 开发错误
⌋(SRS_BSW_00327, SRS_BSW_00337, SRS_BSW_00350, SRS_BSW_00385)

7.12.2 运行时错误（Runtime Errors）

错误类型	相关错误代码	值（十六进制）
唤醒期间的RAM检查失败（参见7.5.2节“暂停序列中的活动”）	ECUM_E_RAM_CHECK_FAILED	由实现分配
后构建配置数据不一致（参见7.3.2节“StartPreOS序列中的活动”）	ECUM_E_CONFIGURATION_DATA_INCONSISTENT	由实现分配

表8 - 运行时错误

7.12.3 瞬态故障（Transient Faults）

不存在瞬态故障。

7.12.4 生产错误（Production Errors）

不存在生产错误。

7.12.5 扩展生产错误（Extended Production Errors）

不存在扩展生产错误。

7.13 错误检测（Error detection）

[SWS_EcuM_04033]⌈在表7第一列定义的不可恢复错误情况下，ECU管理器模块应调用EcuM_ErrorHook回调，并将参数值设置为相应的相关错误代码。⌋()

对SWS_EcuM_04033的说明：ECU管理器应假设EcuM_ErrorHook不会返回（集成商代码）。

对SWS_EcuM_04033的说明：如果需要报告DEM错误，集成商有责任定义处理策略（例如：由于ECU管理器不直接调用DEM，可在复位恢复后设置DEM错误）。

[SWS_EcuM_04139]⌈如果操作系统函数调用失败且未定义其他故障反应，ECU管理器不应更改请求的状态。在这种情况下，应通过EcuM_ErrorHook()进行错误报告。⌋()

注意：调用EcuM_ErrorHook()时使用的确切错误代码取决于操作系统函数及其返回值，未进行标准化。